Контроль версий результатов - PullRequest
       21

Контроль версий результатов

4 голосов
/ 12 сентября 2008

Нам необходимо регулярно синхронизировать многие десятки двоичных файлов (исполняемые файлы проекта и библиотеки DLL) между многими разработчиками в нескольких разных местах, чтобы у каждого разработчика была современная среда для сборки и тестирования. В связи с характером проекта, обновления должны производиться часто и по требованию (ночных обновлений недостаточно). Это не красиво, но мы застряли на некоторое время.

Мы остановились на использовании обычной системы контроля версий (исходного кода): поместите все в нее в виде двоичных файлов, получите последнюю версию перед тестированием и зарегистрируйте обновленную DLL после тестирования.

Он отлично работает, но у клиента контроля версий есть много функций, которые не имеют смысла для нас, и люди иногда путаются.

Существуют ли какие-либо инструменты, лучше подходящие для этой задачи? Или может быть совершенно другой подход?

Обновление:

Мне нужно уточнить, что это не тесно интегрированный проект, а скорее расширяемая система с кучей «плагинов», в том числе сторонних. Мы должны убедиться, что эти модули-плагины прекрасно работают с последними версиями друг друга и ядра. Централизованная сборка, как было предложено, рассматривалась изначально, но это не вариант.

Ответы [ 6 ]

4 голосов
/ 12 сентября 2008

Я бы, наверное, взглянул на rsync.

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

Что не делает rsync, так это разрешение конфликтов (или даже обнаружение), но в описанном вами сценарии это больше похоже на чтение из центрального места, для которого rsync предназначен для обработки.

3 голосов
/ 16 сентября 2008

Другой вариант - унисон

1 голос
/ 12 сентября 2008

Вы должны обратить внимание на непрерывную интеграцию и наличие какого-то централизованного процесса сборки. Я могу только представить, какого черта ты переживаешь, используя свой нынешний подход.

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

0 голосов
/ 16 сентября 2008

Subversion действительно хорошо обрабатывает двоичные файлы, работает довольно быстро и поддерживает скрипты. VisualSVN и TortoiseSVN также упрощают работу с Subversion.

Вы можете создать папку, извлеченную из Subversion, со всеми вашими бинарными файлами (которую все разработчики могут загружать и обновлять), затем просто введите «svn update» в командной строке или используйте TortoiseSVN: щелкните правой кнопкой мыши папку нажмите «SVN Update», и он обновит все файлы и сообщит вам, что изменилось.

0 голосов
/ 12 сентября 2008

Как насчет встраивания строки 'what' в исполняемые файлы и библиотеки. Затем вы можете синхронизировать нужный список версий с манифестом.

Мы склонны использовать строки идентификатора CVS как часть строки what.

const char cvsid[] = "@(#)INETOPS_filter_ip_$Revision: 1.9 $";

Ввод команды

what filter_ip | grep INETOPS

возвращает

INETOPS_filter_ip_$Revision: 1.9 $

Мы делаем это для всех результатов, чтобы увидеть, соответствуют ли версии в комплекте библиотек и исполняемых файлов списку в соответствующем манифесте.

НТН.

ура

Rob

0 голосов
/ 12 сентября 2008

Построение проекта должно быть централизованным процессом, чтобы обеспечить лучшее управление в ближайшее время. В любом случае, вот что я сделаю.

  • Создание обычных хранилищ для исходные файлы, ресурсы, документация и т. д. для каждого проекта.
  • Создать хранилище для ресурсов. Там будет последний бинарный файл версии для каждого проекта, а также любые необходимые ресурсы, файлы и т. д. Держите хорошую структуру папок для каждый проект, чтобы разработчики могли "ссылаться" на файлы напрямую.
  • Создание хранилища для окончательных версий который будет держать фактическую конюшню релиз. Это получит стабильную файлы, сделанные в автоматическом режиме (если возможно) из проверенных источники. Это будет держать реальный продукт, реальная версия для интеграционное тестирование и пр.

Хотя это далеко не идеально, вы сможете определять хорошо установленные протоколы. Проверьте свою последнюю dll здесь, сгенерируйте «реальную» версию из последнего источника здесь.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...