CVS-системы в Domino

Тема в разделе "Общие вопросы по лотус-технологиям", создана пользователем doc, 11 ноя 2009.

Статус темы:
Закрыта.
  1. doc

    doc Гость

    Есть ли какие-нибудь аналоги CVS или Subversion бесплатное для Lotus?
     
  2. Omh

    Omh Lotus team
    Lotus team

    Регистрация:
    4 июл 2007
    Сообщения:
    2.210
    Симпатии:
    0
    Teamstudio CIAO?
    Но мне не нравиться.

    Прошу прощения, не прочитал слово бесплатное.
    Туплю сегодня.
     
  3. doc

    doc Гость

    TeamStudio скачал, установил, но нет ключа, чтобы посмотреть
     
  4. TIA

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Свяжитесь с ними. Они дают триальные ключи.
     
  5. KFire3

    KFire3 Гость

    А разве CIAO это аналог CVS или Subversion ?

    CheckIn, CheckOut CIAO делать умеет, но вроде больше ничего он не умеет.
     
  6. TIA

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Самое главное, что "CIAO!" умеет сохранять версии элементов дизайна и баз данных. Чек-ин, чек-аут тоже вещь приятная, но не главная (для меня по крайней мере)
     
  7. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    указанным ПО не пользовался, но ЧАО умеет хранить версии элементов дизайна, и можно откатить.
    обычная проблема, что часто не оставляют комментов при чеках, и не понятно какая версия чего имеет

    от млин, тоже туплю... TIA уже все написал )
     
  8. vincent_vega

    vincent_vega Lotus team
    Lotus team

    Регистрация:
    2 апр 2005
    Сообщения:
    165
    Симпатии:
    1
    Поделитесь как удалось прикрутить SVN к лотусу.
     
  9. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    SVN удалось прикрутить к DDE. При этом лотусовые базы запихнуть в svn не получица. Именно поэтому написал, что толку почти нет.
    Подробно - тут: http://lotus-blogs.blogspot.com/2009/10/de...on-control.html

    Однако, если потихоньку мигрировать со скрипта на java и далее в сторону xpages - оно имеет смысл.
    http://www.mindoo.com/web/blog.nsf/dx/15.0...p;comments#anc1
    Основаня рабочая папка в этом случае - webcontent/web-inf/src. Вот ее и нужно размещать в svn.
     
  10. vincent_vega

    vincent_vega Lotus team
    Lotus team

    Регистрация:
    2 апр 2005
    Сообщения:
    165
    Симпатии:
    1
    Спасибо за линки, посмотрю на досуге. Когда полгода назад пытался установить плагины, то ничего не вышло. Интересует как раз java, основная масса кода на ней:please:
     
  11. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    Лена ссылку дала на SVN. Спасибо!
     
  12. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.075
    Симпатии:
    300
    Вот тута искал ч-л для сравнения файлов, да ещё с анализатором блоков по языкам... ничё "толкового" не нашёл, простые сравнивалки есть, но маловато. Може кто знает?!
    Из просмотренного:
    -meld
    -Kompare
    -codecompare (виндовзонли)
    -jedit (плагин под него)
    -diffmerge
    -deltawalker (здесь я ваще не понял - за что деньги берут - тока за сохранение сессии чоль)
    платны практически не рассматривал
    более-менее поддержку языков увидел в codecompare
    meld и Kompare по-своему хороши (по линухами)
    сморел списочек здесь http://www.noupe.com/tools/25-useful-docum...ison-tools.html
    и здесь http://stackoverflow.com/questions/12625/best-diff-tool
     
  13. vital

    vital Больной Компом Детектед
    Команда форума Web Team

    Регистрация:
    29 янв 2006
    Сообщения:
    2.470
    Симпатии:
    27
    Юзаю мелд или встроенную сравнивалку нетбинса. Вроде хватает.
     
  14. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.075
    Симпатии:
    300
    "беда" в том что все они "не больше" чем diff (с графической обвязкой)
    а нужен анализатор кода и перемещённых блоков
     
  15. Кирилл Шваб

    Кирилл Шваб Well-Known Member

    Регистрация:
    30 июн 2006
    Сообщения:
    144
    Симпатии:
    4
    Пардон, за офтоп, но раз уж вопрос был затронут.

    lmike,
    Контроль версий при желании можно прикрутить, т.к. IBM в версии 8.5.3 добавили штатную возможность выгрузки содержимого лотусовой базы на файловую систему (раньше тоже можно было, но надо было плагин ставить или делать свою выгрузку DXL'ом).
    А файлы с диска уже можно пихать в какую-нибудь систему контроля версий.

    Посмотрите вот этот ролик (первые 4 минуты можно пропустить):
    http://notesin9.com/index.php/2012/01/29/n...-souce-control/

    Если заинтересует, то можно в отдельной теме потом обсудить.
     
  16. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.075
    Симпатии:
    300
    я полагаю не только мне будет интересно
    видео просмотрел бегло, но впечатлило
    остались вопросы о кроссплатформенности (кот. не решен в дизигнере) и diff утилитах...
    ибо контроль версий - это здорово, но хотелось бы и понимать что изменили

    Добавлено:
    а вот отсюда можно поподробней :) и еще - возможно ли импортировать (опять же штатно из меню)
     
  17. Кирилл Шваб

    Кирилл Шваб Well-Known Member

    Регистрация:
    30 июн 2006
    Сообщения:
    144
    Симпатии:
    4
    lmike,
    Лучше не бегло посмотреть, я несколько раз смотрел, т.к. давно ждал прихода CVS в мир Lotus'а (TeamStudio не считается, т.к. у них ценники ого-го).
    Да, кроссплатформенности пока нет, т.к. штатный дизайнер есть только под Windows.
    Diff работает, т.к. сейчас в любой нормальной CVS есть инструменты для отображения изменений между коммитами, т.е. можно наглядно видеть что где изменилось.
    Единственное, надо для начала в дизайнере в "File" -> "Preferences" -> "Domino Designer" -> "Source Control" снять галку напротив "Use Binary DXL for source control operations". Если ее оставить, то часть элементов дизайна (формы, агенты и много чего еще) будет выгружаться закодированными в Base64 (<rawitemdata>абракадабра</rawitemdata>) и от сравнения различий толку не будет.
    Насколько я понял, в общих чертах это выглядит примерно так:
    1. Устанавливается плагин для работы с CVS
    2. Лотусовая БД выгружается на диск
    3. Делается коммит выгруженной базы в "локальное хранилище"
    4. А из локального хранилища уже можно пушить данные в нормальную CVS (если надо)
    В дизайнере 8.5.3 на какой-нибудь открытой базе нажми правую кнопку - в конце списка должен быть пункт "Team Developement" (может он после установки плагина появляется, но по-моему должен сразу быть).
    Да, импортировать из CVS можно, только сначала надо чтобы туда кто-то базу закоммитил. :)

    P.S.
    Я сейчас как раз занимаюсь установкой CVS в своей компании и позже планирую описать "свой опыт".
     
  18. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.075
    Симпатии:
    300
    с нетерпением ждем :)
     
  19. Yakov

    Yakov Гость

    Здравствуйте, уважаемые коллеги.

    На форуме неоднократно поднимался вопрос об использовании систем управления версиями (СУВ, VCS - version control system) при разработке под Lotus.
    В этой небольшой заметке я хочу поделиться своим опытом работы с СУВ.
    Замечу, что у меня нет опыта по-настоящему командной разработки ПО под Lotus. Модули (отдельные БД) у нас пишутся разными программистами, межмодульное взаимодействие согласовывается. Итак, первый вопрос - зачем, по сути, разработчику-одиночке СУВ?

    <div class="sp-wrap"><div class="sp-head-wrap"><div class="sp-head folded clickable">1. Почему СУВ</div></div><div class="sp-body"><div class="sp-content">
    В настоящее время я занимаюсь разработкой некой системы на Lotus Domino/Notes. Система не коробочная, она настраивается для каждого заказчика, причем обойтись "настроечными" документами нет никакой возможности.
    Как велась разработка в до-СУВ эпоху: выделялась некая общая базовая часть системы ("ядро") в один или несколько шаблонов, с них наследовались шаблоны для каждого заказчика. Такая схема, наверняка, многими используется. Недостатки такого подхода таже всем известны. Это, во-первых, дублирование элементов дизайна (не только кода), когда некая "фича" используется несколькими заказчиками и не входит в ядро. Или входит в ядро, но у некоторых заказчиков она несколько изменена и не наследуется с базового шаблона - по сути, дублируется. Во-вторых, проблемы при обновлении дублируемых элементов: как бы не забыть обновить везде и не потерять кастомное поведение. Есть и другие проблемы, но дублирование и производные от него - это, на мой взгляд, самое страшное.
    Чем здесь может помочь СУВ? Автоматизацией дублирования. Создаем базовый шаблон и связанный с ним репозитарий on-disk проекта. Это может быть и не "наибольшая общая часть" системы (то самое "ядро"), а шаблон первого/самого важного/самого "фичастого"/и т. д. и т. п. заказчика. Репозитарий клонируем одной командой необходимое число раз. С каждого такого "клона" восстанавливаем ntf(nsf)-шаблон и вносим необходимые правки. Дальнейшее распространение изменений (новые "фичи", исправления ошибок и пр.) происходит практически при помощи нескольких простых команд.
    О проблемах использования СУВ будет сказано ниже. А сейчас -


    <div class="sp-wrap"><div class="sp-head-wrap"><div class="sp-head folded clickable">2. Выбор СУВ</div></div><div class="sp-body"><div class="sp-content">
    Я рассматривал только две системы: Mercurial (hg) и Git. Естественно, под Windows. Желательно, с GUI. GUI-надстройки были TortoiseHg и TortoiseGit.
    Очень важный момент, который повлиял на выбор СУВ, - это наличие элементов дизайна с названиями на русском языке. На дворе 2012 год, и неумение инструмента работать с файлами с произвольными именами, по-моему, просто неприлично.
    Не буду тянуть кота за хвост, а скажу сразу, что в итоге я остановился на git в консольном (!) варианте. Причина одна - то самое неприличное неумение инструмента "готовить" русские имена файлов.
    Начал я с более понравившегося мне инструмента - Mercurial и его GUI-оболочки TortoiseHg. Выбор был в пользу hg еще и потому, что есть плагин для дизайнера. (К слову, отсутствие аналога для git совершенно не мешает. Да и пользовался я плагином только для commit-ов. Все остальные действия делал внешними инструментами.) Работал я с TortoiseHg довольно продолжительное время, пока не столкнулся с конфликтом слияния элемента дизайна с русским названием.
    Мой типичный сценарий работы такой (подробнее будет ниже):
    1) внесение изменений в базовый шаблон;
    2) commit (фиксация) изменений в vcs;
    3) pull (вытягивание) изменений из базового репозитария в производный;
    4) при необходимости - разрешение конфликтов слияния (пользовался штатным в TortoiseHg инструментом KDiff3) и commit изменений в производном репозитарии;
    5) синхронизация дизайнером on-disk версии и nsf-версии, выборочная визуальная проверка результата.

    И вот однажды изменения в форме, допустим, "Документ" не пришли во второй шаблон. Это заставило разобраться, что происходит. После гуглёжа и экспериментов я пришел к выводу, что с hg пора расставаться.

    Если интересно, как воспроизвести проблему слияния файлов с русскими именами, то я напишу отдельным комментарием. А сейчас посмотрим, каким образом дизайнер работает с on-disk проектами.


    <div class="sp-wrap"><div class="sp-head-wrap"><div class="sp-head folded clickable">3. Особенности Lotus</div></div><div class="sp-body"><div class="sp-content">
    Domino Designer 8.5.3 (и 8.5.2) умеет создавать on-disk версию БД и синхронизировать ее с nsf-версией. Он также умеет создавать nsf-версию БД по on-disk версии.

    Создайте on-disk версию какой-нибудь базы. (Для Designer 8.5.3 - правой кнопкой на БД в навигаторе, меню Team Development\Set Up Source Control for this Application...)
    Дизайнер выгрузит все документы дизайна в файловую систему и аккуратно разложит их по каталогам. Файлы элементов дизайна представляют собой xml-документы, те же самые, что создаются при DXL export.
    Помимо собственно дизайна элемента, xml-документ содержит массу метаданных: ReplicaID БД, NoteID и UNID документа дизайна, ревизия документа - sequence, даты создания/измения и т. д. Исключение здесь - Lotus Script библиотеки. Для них код сохраняется в одном файле, а метаданные - в другом.
    Наличие метаданных в файлах документов дизайна - это большая и самая главная проблема использования СУВ при разработке под Lotus. Метаданные - это причина совершенно необоснованных (с точки зрения здравого смысла) конфликтов слияния.
    Создали nsf-проект по on-disk проекту - получите новые ReplicaID во все элементы дизайна. И дата изменения тоже будет новая.
    Сохранили элемент дизайна в дизанере - получите следующий sequence number в соответствующем файле. И дата изменения тоже обновится.
    Используете таблицы для верстки форм? Изменили размер окна дизанера (если оно не распахнуто на весь экран) или другим образом изменили ширину области дизанера, в которой отображается форма, - при сохранении формы получите изменение атрибутов refwidth всех элеметов table.
    И теперь, если были внесены изменения в один и тот же элемент дизайна в базовом и производном шаблоне, то при слиянии получите конфликты "на пустом месте", хотя, возможно, внесенные вами изменения, ради которых все это и затевалось, сольются автоматически без конфликта.

    Еще одна "особенность" создания nsf-базы по on-disk проекту - это ошибки компиляции LS-библиотек, которые возникают, скорее всего, из-за нарушения порядка импорта библиотек и их компиляции. Лечится открытием проблемных библиотек (у них нет полей $ScriptLib и $ScriptLib_O, но есть поле $ScriptLib_error), изменением в них чего-нибудь (вставить пробел и удалить его) и сохранением. После этого я еще делаю Recompile All LotusScript.

    Ну и как со всем этим работать?


    <div class="sp-wrap"><div class="sp-head-wrap"><div class="sp-head folded clickable">4. Мои процедуры</div></div><div class="sp-body"><div class="sp-content">
    0. Устнановка и настройка Git

    Информации об установке и настройке Git под Windows в сети достаточно.
    Я устанавливал msysgit с опцией git-bash (что-то такое, вторая в списке опций в установщике).
    На Хабре описаны некоторые Особенности настройки git под windows. Из приведенных там советов я воспользовался только опцией
    Код (Text):
    quotepath = false
    Тексты коммитов пишу в Notepad++ в кодировке UTF-8 without BOM, для этого в git установил опцию
    Код (Text):
    editor = \"C:\\Program Files (x86)\\Notepad++\\notepad++.exe\" -multiInst -nosession
    1. Создание on-disk проекта для базового шаблона

    On-disk проекты я создаю в специально отведенном для этого месте - каталоге C:\Work\repo. Не забывайте делать регулярное резервное копирование этого каталога, СУВ не панацея!
    Например, для шаблона test.ntf для заказчика customer1 будет создан проект test-customer1 и помещен в каталог C:\Work\repo\test-custormer1\db
    Я помещаю проект в подкаталог db, потому что в каталоге test-customer1 будет создан служебный каталог .git, и если он будет в том же каталоге, что и созданные дизайнером каталоги с документами дизайна, то заботливый дизайнер поместит каталог .git в ресурсы БД при синхронизации. (Надеюсь, понятно объяснил. Если нет, попробуйте поместить все в одно место и посмотрите, что получится. :))

    2. Создание репозитария для базового шаблона

    В каталоге test-customer1 я создаю файл .gitignore следующего содержания:
    Код (Text):
    db/.settings/
    db/.classpath
    db/plugin.xml
    db/Code/ScriptLibraries/*.lss.metadata
    Этот файл указывает git, какие файлы не нужно отслеживать.

    Далее в git-bash я говорю:
    Код (Text):
    cd /C/Work/repo/test-customer1/
    git init
    git add .
    git commit
    Пишу комментарий к первому коммиту ("Начало."), сохраняю и закрываю Notepad++.

    3. Клонирование репозитария для производного шаблона (для заказчика customer2)

    В git-bash:
    Код (Text):
    cd ..
    git clone test-customer1 test-customer2
    В файле test-customer\db\.project правлю название проекта на test-customer2, чтобы не было конфликтов при открытии этого проекта в том же Workspace дизайнера, в котором открыт проект test-customer1.

    4. Создание ветки во втором репозитарии и первый коммит в нем

    В git-bash:
    Код (Text):
    cd test-customer2
    git checkout -b customer2
    git commit -a
    Я делаю отдельную ветку в этом репозитарии, в которую буду коммитить специфичные для заказчика изменения. Это будет основная рабочая ветка для этого репозитария. О работе с ветками чуть ниже.

    Сейчас зафиксировано только новое имя проекта.

    5. Создание nsf-базы по on-disk проекту

    В дизайнере в навигаторе в контекстном меню Import..., далее выбираю Existing Project into Workspace, нахожу C:\Work\repo\test-customer2\db, импортирую.
    Далее, правой кнопкой на этот проект - Team Development\Associate with New NSF...
    Далее, в только что созданной базе компилирую библиотеки (см. выше), делаю Recomile All LotusScript

    6. Коммит новой базы в репозитарий

    Как я говорил выше, после создания новой БД во все документы дизайна будет записано новое значение ReplicaID базы. Эти изменения нужно зафиксировать в репозитарии (в ветке customer2).


    А теперь рутина.
    Сначала опишу процесс в общем и целом, потом покажу пример.

    Есть очень хорошая статья "Удачная модель ветвления для Git" (перевод на Хабре), но мой процесс ей не полностью соответствует.

    Новые "фичи" разрабатываются в базовом шаблоне. Для каждой фичи создается своя ветка. Эти ветки после завершения разработки вливаются в ветку master.
    Во "вторичных" шаблонах ветка master используется только для синхронизации с базовым шаблоном. Основной рабочей ветке для такого шаблона я даю имя заказчика. Фичи заказчика создаются в отдельных ветках, порождаемых от основной рабочей, которые потом вливаются обратно в рабочую ветку.
    Перенос новой фичи из базового шаблона происходит так: в ветку master вторичного шаблона втягивается ветка master основного шаблона. Конфликтов слияния здесь нет. Затем ветка master вторичного шаблона вливается в основную рабочую ветку. Конфликтов здесь полно по описанным выше причинам.


    7. Создание фичи
    а) в основном шаблоне
    Код (Text):
    git checkout -b featureX
    git add .
    git commit
    git checkout master
    git merge --no-ff featureX
    git branch -d featureX
    б) во вторичном шаблоне все то же самое, но вместо
    Код (Text):
    git checkout master
    делаю
    Код (Text):
    git checkout customer1
    8. Вливание новой фичи из основного шаблона во вторичный
    Работа в репозитарии вторичного шаблона.
    Код (Text):
    git checkout master
    git pull origin master
    git checkout customer1
    git merge master
    9. Разрешение конфликтов слияния
    Для всех файлов, которые git не сможет слить, будут созданы diff-файлы. Конфликты нужно разрешить, добавить измененные файлы в индекс и зафиксировать:
    Код (Text):
    git commit -a
    Для разрешения конфликтов слияния я сейчас использую WinMerge. Но тут я не советчик, надо подбирать удобный инструмент.
    Конфликты слияния, вызванные изменениями в метаданных, я разрешаю в пользу версии вторичного репозитария (ветки customer1). Если после этого дизайнер ругается на рассинхронизацию nsf- и on-disk версий, приоритет отдаю on-disk версии; после этого приходится делать еще один "синхронизационный" коммит.


    А теперь задавайте ваши ответы. :)

    P. S. Книжка про git: http://progit.org/book/ru/
     
    2 пользователям это понравилось.
  20. ToxaRat

    ToxaRat Чёрный маг
    Lotus team

    Регистрация:
    6 ноя 2007
    Сообщения:
    3.046
    Симпатии:
    18
    а смысл тогда писать? :)
     
Загрузка...
Статус темы:
Закрыта.

Поделиться этой страницей