Альтернатива двоичным файлам в Subversion

Question

Некоторые мои коллеги убеждены, что отправка артефактов сборки в хранилище Subversion - хорошая идея. Аргумент в том, что таким образом установка и обновление на тестовых машинах просты - просто "svn up"!

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

Это для кода Java, если это имеет значение. Все скомпилировано из Eclipse (без автоматических сборок PDE).

Когда я говорю добавить артефакты сборки, я имею в виду, что коммит будет выглядеть так:

"Added the new Whizbang feature"

 M src/foo/bar/Foo.java
 M bin/Foo.jar

Каждое изменение кода имеет соответствующий сгенерированный файл JAR.

Answer 1

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

Answer 2

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

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

Поскольку такие вещи, как изображения, не обладают концепцией различия, ПОЧЕМУ вы храните их в системе, в которой существует запись, и храните различия между файлами?

Хранилище на основе ревизий предназначено для хранения историй изменений в файлах. В данных файлов JPEG, скажем, нет никакой истории изменений. Такие файлы отлично хранятся просто в каталоге.

Практически, хранение больших файлов - сборка выходных файлов - в SVN ускоряет оформление заказа. Существует вероятность злоупотребления SVN как обобщенного бинарного хранилища. Сначала все выглядит хорошо - потому что не так много двоичных файлов. Конечно, количество файлов увеличивается с течением времени; Я видел модули, которые часов проверяют.

Лучше хранить большие связанные двоичные файлы (и выходные файлы) в структуре каталогов и ссылаться на них из процесса сборки.

Answer 3

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

Вот почему: если вы можете легко восстановить свое архивное состояние работы из других файлов этой определенной версии, как, например, с помощью простой перекомпиляции или установки стандартных установок, вам не следует фиксировать такие двоичные файлы, а делать что-то вроде README или УСТАНОВИТЬ файл. Если трудности или риск невозможности реконструкции слишком велики, сделайте коммит.

Answer 4

• Subversion - это менеджер управления исходным кодом -> Двоичные файлы не являются исходными
• Если вы используете команду «svn up» для обновления производства, все разработчики с разрешениями коммита могут обновить / изменить / прервать производство?

Альтернативы: используйте непрерывную интеграцию, такую ​​как Hudson или Cruise Control.

Answer 5

Вы имеете в виду, что у вас есть источники плюс результат сборки в том же хранилище?

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

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

Пропагандируйте ежедневный, отдельно обновляемый скрипт автоматической сборки, а не только двоичные файлы + код