призыв к пониманию: контроль версий и двоичные файлы - PullRequest
Новая
       0

призыв к пониманию: контроль версий и двоичные файлы

8 голосов
/ 21 ноября 2010

человек запись исходного кода

контроль версий используется для записи изменений в исходном коде

инструменты обработка исходного кода и генерация машинногочитаемый материал (exec, libs, код GUI и т. д.)

время от времени я хотел бы сохранить копию вывода tools ' (например, сохранить исполняемый файл бета-релиза)для АРМ).я могу вручную сохранить вывод tools ', дав ему имя, которое отражает точку в истории контроля версий (например, использовать имя тега).это кажется неудобным и подверженным ошибкам.

Мне бы хотелось, чтобы вы ознакомились с двумя вещами:

  1. Каковы плюсы / минусы использования контроля версий для хранения сгенерированных инструментоввыводить на определенные позиции в графе истории ревизий?какие инструменты, не относящиеся к RCS, вы используете в качестве альтернативы?

  2. в mercurial, git, каков наилучший способ включить сгенерированный инструментом вывод в определенные ревизии, а не в другие

Ответы [ 2 ]

8 голосов
/ 22 ноября 2010

Я считаю, что двоичные файлы не должны храниться вместе с их исходным кодом в системе управления версиями.

Недостатки:

  • это поощряет плохие методы сборки в больших проектах. Рекомендуется полностью автоматизировать полную сборку (не только исходную компиляцию, но также запускать автоматические тесты, упаковку документации, генерацию установки и так далее). Фиксация двоичных файлов позволяет вам игнорировать следующее: «просто выполните сборку для измененных частей».
  • медленные обновления и коммиты
  • необходимо иметь дело с конфликтами в двоичных файлах каждый раз, когда вы обновляете после выполнения сборки
  • коммиты, которые изменяют исходный код, но не соответствующие двоичные файлы, вызовут путаницу среди разработчиков. Как вы обнаружите, что есть несоответствие?
  • svn update обновит временную метку ваших двоичных файлов, что приведет к путанице в инструментах сборки, которые будут ошибочно думать, что двоичные файлы новее, чем изменения исходного кода.
  • он использует больше дискового пространства в хранилище. (Это может быть незначительным в зависимости от вашего проекта.)

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

Вместо этого используйте сервер непрерывной интеграции, чтобы автоматически перестраивать (и запускать тесты) каждый коммит. Пусть этот сервер сборки опубликует двоичные файлы где-нибудь (за пределами SVN), если это необходимо, например, общую папку в сети.

4 голосов
/ 22 ноября 2010

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

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

Чтобы такое разделение не было «неловким и подверженным ошибкам», как вы говорите, постарайтесь максимально автоматизировать его. Создайте автоматизированную процедуру сборки, которая гарантирует, что источник версионируется / помечается, выполняет полную сборку и помещает выходные данные (с правильными именами, версией, помеченными и т. Д.) В назначенное хранилище.

...