У нас есть проект разработки на Python (ArcGIS 10). Этот проект включает в себя сочетание наборов инструментов, шаблонов карт, файлов слоев, шаблонов файловой базы геоданных (действующих в качестве шаблонов, импортируемых в карту с помощью сценариев) и различных других вещей.

Мы используем Eclipse в качестве редактора исходного кода и SVN в качестве репозитория исходного кода.

Хотя у нас есть проблема с сохранением всех файлов (которые не являются py-файлами) в синхронизированном проекте всеми. Набор инструментов обычно запутывается несколькими людьми, редактирующими набор инструментов, и затем файлы шаблона корректируются, а затем не обновляются для других людей, поскольку они не возвращаются обратно.

Как люди в организациях с более чем одним разработчиком Python в проекте набора инструментов компании гарантируют, что проект и все различные файлы будут версионированы и правильно управляются? Или это случай, когда все входит в Eclipse (включая слои шаблонов и GDB, используемые сценариями) в проект и надеется, что люди проверят файлы правильно?

Если я знаю, что собираюсь работать с другими разработчиками, то первое, что я делаю в настоящее время, это настройка сервера интеграции Continuos, такого как Jenkins .

Идея состоит в том, чтобы всегда запускать ваш набор тестов после каждой регистрации, и вы сразу получите автоматическое электронное письмо, если оно не пройдет. В вашем случае это может быть простой скрипт Selenium . Это щелкает браузером или скриптом ArcObjects, который автоматизирует ArcMap. Есть несколько презентаций о Selenium .

Крутая вещь в Jenkins заключается в том, что есть несколько плагинов, которые позволяют интегрировать / использовать другие технологии (системы сборки, lint и т . Д.) . Вы можете получить потрясающие отчеты о том, сколько кода покрывается тестом. Они действительно просты в настройке .

Лично вместо SVN мне нравится интегрироваться с Git и GitHub ... есть несколько преимуществ, например, использование GitHub для аутентификации.

Но, конечно, первый шаг - запустить Дженкинса. Если вы никогда не делали этого, зарезервируйте один день и много дышите, потому что это может быть очень странно ... но как только вы запустите его, это действительно здорово.

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

Так что, может быть, вы можете попробовать пару вещей:

Установить четкую политику использования репозитория

Разъясните всем разработчикам, как использовать репозиторий, когда и что делать. Поэтому в хранилище всегда есть рабочая копия проекта.

Использовать распределенную систему управления

Если вы используете распределенную систему управления, такую ​​как Git или Mercurial , каждый пользователь может зафиксировать свой репозиторий и отправлять свои версии в централизованное хранилище только тогда, когда он уверен, что он будет работать, вы можете даже установить окна фиксации для каждого пользователя, чтобы они не Не наступайте на код друг друга.

Сказав это, в вашем случае я бы пошел на Mercurial, потому что он разработан на Python, и вы можете создавать крючки, чтобы адаптировать его к вашим потребностям. А поскольку освоить SVN очень просто ... неплохо начать с учебника по hginit , в котором на самом деле есть раздел под названием « Переобучение SVN».

Я думаю, что вам нужен кто-то ответственный и более ответственный. Я бы предложил назначить или нанять администратора для набора инструментов. Сделайте общедоступный набор инструментов и все в его пространстве доступными только для чтения, кроме администратора. Администратор может быть ответственным за то, чтобы убедиться, что все проверено, проверено (или управляется - в случае элементов вне пространства SVN). Поскольку администратор получит возможность увидеть, что делают люди, он / она узнает, когда кто-то нуждается в обучении, т. Е. Он может поймать людей, которые делают вещи ненадлежащим образом.

Это проблема людей, а не проблема технологий. Панель инструментов и файлы шаблонов редактируются вне системы контроля версий, поэтому контроль над ними отсутствует. Эти файлы должны находиться в режиме контроля версий, даже если они являются двоичными файлами, и их нельзя сравнивать или сравнивать. Как общее правило Thumb, все, что не сгенерировано из вашего кода и требуется для запуска или компиляции кода, должно находиться под управлением исходного кода.

Таким образом, весь проект будет находиться под контролем исходного кода, и всегда будет рабочая копия. Разработчики должны отредактировать набор инструментов и шаблон в своей локальной версии после блокировки и зафиксировать их, когда работает их локальная копия.

Относительно

... не обновляется для других людей, так как они не зарегистрированы в

Это проблема людей, и если все ваши разработчики не поймут, почему это важно, никакие технологии не помогут.

Набор инструментов обычно запутывается несколькими людьми, редактирующими набор инструментов

Для этой конкретной проблемы мы помещаем наш набор инструментов в базу данных ArcSDE. Я не пробовал с другим типом базы данных! Если два человека не редактируют один и тот же инструмент одновременно, он прекрасно работает. На самом деле проблем меньше, чем с файловой панелью инструментов (.tbx).