Плагин eGit для Xpages Project VS Процесс репликации заметок для обмена кодом в команде или разработчике

Question

С этим вопросом я просто хочу получить комментарии и советы по обоим процессам.

Я специально упомянул плагин eGIT, потому что могу предположить, что GIT - это популярная VCS, которая обновляет код для git-сервера и все остальное, например, копирование, ветвление и т. Д. Но в Xpages нам нужно создать проект ON-Disk, и ему нужно управление исходным кодом с локальным ntf, чтобы мы могли синхронизировать изменения от проекта git ondisk к локальному ntf и наоборот, в котором плагин eGIT помогает нам настроить его.

Для более подробного объяснения у нас есть 2 разных местоположения (оба часовых пояса различаются), пример местоположения A и местоположения B. В местоположении A кажется, что все работает хорошо, но в местоположении B, когда изменения записываются на диск В рамках проекта некоторые из наших разработчиков обнаружили проблему с синхронизацией с проектом ondisk и не получили изменений из проекта ondisk (иногда это может быть связано с созданными метаданными), где мы нашли возможные причины этого. Итак, мы решили до

1. создать репликацию из одного основного шаблона "xyz" из местоположения B в Расположение "A" на всех разработчиков локально, шаблон "XYZ" и реплицировать, когда изменения сделаны.
2. Хватит тянуть изменения из мерзавца
3. решил только проталкивать изменения и реплицировать изменения на основной шаблон "xyz" на месте "A".

Теперь вопрос о том, насколько корректен процесс репликации, когда работает несколько разработчиков, и репликация там меняется, насколько безопасным будет код от всех разработчиков, работающих в местоположении «A».

С какими проблемами столкнулся любой разработчик xpages при использовании плагина egit для синхронизации изменений в локальном шаблоне.

Как репликация будет работать здесь поверх процесса git с использованием eGit, Какие возможные проблемы можно ожидать с процессом репликации при работе в команде.

В последние несколько недель мы обнаружили, что после репликации шаблона из местоположения «A» в местоположение «B» некоторые пользовательские элементы управления дублируются с другим подписывающим лицом, но с тем же именем. Теперь никто не может предсказать, что здесь пошло не так.

Answer 1

Контроль исходного кода для проекта NSF настолько плох, насколько это возможно. Единственное, что вы можете сделать, чтобы смягчить различные проблемы, - это отказаться от некоторых базовых допущений, которые являются абсолютной нормой в любой другой уважаемой среде разработки, и развернуть стратегии, подобные акробатическим петлям.

Я полагаю, у вас уже есть:

1. отключена двоичная опция DXL (DDE Source Control)
2. включил автоматический импорт / экспорт элементов дизайна (DDE Source Control)
3. включена опция автоматической сборки (DDE Workspace)
4. включено обновление с использованием собственных перехватчиков или опроса (DDE Workspace)
5. установлен OpenNTF Swiper плагин и активирован для проекта

---

Оттуда я бы организовал работу, чтобы иметь своего рода нисходящую конфигурацию, соответствующую шаблону. Это значит:

• каждый разработчик имеет свой собственный локальный экземпляр шаблона (и, следовательно, другой идентификатор шаблона), созданный и синхронизированный с проектом git с включенным диском
• каждый разработчик работает со своим локальным сервером (и, следовательно, с репликой своего личного локального шаблона) для целей разработки / тестирования
• каждый разработчик фиксирует / выталкивает / извлекает любые изменения в / из удаленного репозитория git
• авторизованный разработчик и / или общий клиент DDE - только один! - создает из и выполняет синхронизацию с проектом на диске с включенным git в другом файле ntf, хранящемся на сервере A или B, - а затем Domino реплицируется на A или B. Этот ntf фактически становится единственным авторизованным рабочим шаблоном, существующим для org

Таким образом, у вас есть четкое разделение между локальными шаблонами dev и шаблоном производственного сервера. Идентификатор реплики для каждого из них различен, и поэтому они никогда не могут реплицироваться между собой, даже по ошибке. Таким образом, вы действительно гарантируете, что источником правды является только то, что контролируется git и избегаете забавных конфликтов репликации / сохранения, типичных для envs domino с несколькими разработчиками, работающими над одним и тем же шаблоном.

Answer 2

Уже много лет использую Git с XPages, также в проектах с несколькими разработчиками.Иногда это боль, но в большинстве случаев это работает довольно хорошо.И это намного лучше, чем вообще не использовать систему контроля версий, особенно в командах разработчиков.Вы просто не можете жить без этого ИМХО.

В приведенном выше тексте нет конкретного вопроса, но я могу поделиться некоторыми своими впечатлениями:

• Я не использую eGit, но внешний клиент Git (SourceTree),Это не потому, что мне не нравится eGit, а потому, что мне не нравится дополнительная зависимость, которую он добавляет в Designer.Мне нравится держать Designer как можно ближе к стандартной установке.
• Используйте Swiper в Designer.Git с файлами NSF - это гораздо большая боль без него.
• Зафиксируйте только то, что вы действительно изменили в NSF.Проект на диске иногда заставляет вас думать, что вы также изменили свойства базы данных или значок (это большая борьба), но просто игнорируйте эти изменения.Если вы забыли, какие файлы вы изменили, вам нужно делать коммиты чаще (сначала коммитить локально, сдавить ваши коммиты и отправить их на сервер).
• Репозиторий Git - единственный и единственный источник правды.При разработке забудьте о шаблонах.Просто синхронизируйте с ODP.По моему опыту, обнаружение и синхронизация изменений ODP стали лучше с новой версией Eclipse в Designer.
• Если вы создаете Git-репо для ODP, храните файлы из NSF всегда в подпапке (или в нескольких, если ваше приложение состоит из нескольких баз данных).
• Если вы объединяете коммиты от кого-тов противном случае выполните слияние в своем клиенте Git, разрешите все конфликты слияния, и только после этого вы синхронизируетесь с NSF.
• Включите автоматический импорт / экспорт в настройках Designer> Source Control.Делает Designer более отзывчивым и дает вам контроль над процессом.Вы просто не должны забывать это делать.