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

Ответ 1

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

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

Если есть скрипты сборки, получение двоичных файлов может быть выполнено с помощью команды, например:

svn update; ant dist

Я думаю, что самая важная причина не проверять двоичные файлы вместе с источником - это результирующий размер вашего репозитория. Это приведет к:

• Более крупный репозиторий и, возможно, слишком мало места для системного сервера версий
• Трафик между сервером системы версий и клиентами
• Более длительное время обновления (представьте, что вы обновляете SVN из Интернета...)

Другая причина может быть:

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

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

Ответ 2

Во-первых, Subversion (и все остальные в настоящее время) не являются менеджерами управления исходными кодами (я всегда думал, что SCM означает Software Configuration Management), но системы контроля версий. Это означает, что они хранят изменения в материалах, которые вы храните в них, это не должен быть исходный код, это могут быть файлы изображений, растровые ресурсы, файлы конфигурации (текст или xml), всевозможные вещи. Там только одна причина, почему встроенные двоичные файлы не должны рассматриваться как часть этого списка, и это потому, что вы можете их перестроить.

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

Во-первых, это система, которая поможет вам, а не рассказывать, как вы должны создавать свои приложения. Сделайте компьютер работать для вас, а не против вас. Итак, что, если сохранение двоичных файлов занимает пространство - у вас есть сотни гигабайт дискового пространства и супер быстрых сетей. Это не большая проблема для хранения двоичных объектов там больше (тогда как десять лет назад это могло быть проблемой - возможно, поэтому люди думают о двоичных файлах в SCM как о плохой практике).

Во-вторых, как разработчик вам может быть удобно использовать систему для восстановления любой версии приложения, но другие, которые могут ее использовать (например, qa, test, support), могут не работать. Это означает, что вам нужна альтернативная система для хранения двоичных файлов, и, действительно, у вас уже есть такая система, ее SCM! Используйте его.

В-третьих, вы предполагаете, что вы можете перестроить из источника. Очевидно, что вы храните там весь исходный код, но вы не храните компилятор, библиотеки, sdks и все другие зависимые биты, которые требуются. Что происходит, когда кто-то приходит и спрашивает: "Можете ли вы построить мне версию, которую мы отправили 2 года назад, у клиента проблемы с этой версией". 2 года - это вечность в наши дни, у вас даже есть тот же самый компилятор, который вы использовали тогда? Что происходит, когда вы проверяете весь исходный код только для того, чтобы узнать, что обновленный sdk несовместим с вашим источником и не удается с ошибками? Вы протираете окно разработки и переустанавливаете все зависимости только для создания этого приложения? Можете ли вы даже вспомнить, каковы были все зависимости?!

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

Итак, храните двоичные файлы в своем SCM, не беспокойтесь о мелочах.

PS. мы вставляем все двоичные файлы в их собственный каталог "release" для каждого проекта, а затем, когда мы хотим обновить машину, мы используем специальный проект "setup", который состоит из ничего, кроме svn: externals. Вы экспортируете проект установки, и все готово, поскольку оно извлекает правильные вещи и помещает их в правильную структуру каталогов.

Ответ 3

Сервер непрерывной интеграции, такой как Hudson, сможет архивировать артефакты сборки. Это не поможет вашему аргументу с "почему бы нет", но по крайней мере это альтернатива.

Ответ 4

Я уверен, что есть веские аргументы против этой плохой практики

У вас неверная презумпция, что фиксация "артефактов сборки" для контроля версий - плохая идея (если вы не ошибочно сформулировали свой вопрос). Это не так.

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

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

Итак, нет причин, по которым вы должны бояться хранить "сборку артефактов" в управлении версиями. Что вы можете сделать, так это сохранить их в разных местах.

Я предлагаю отделить их, как:

 ProjectName
 |--- /trunk
 |    |--- /build
 |    |    |--- /bin        <-- compilers go here
 |    |    |--- /lib        <-- libraries (*.dll, *.jar) go here
 |    |    '--- /object     <-- object files (*.class, *.jar) go here
 |    '--- /source          <-- sources (*.java) go here
 |         |--- package1    <-- sources (*.java) go here
 |         |--- package2    <-- sources (*.java) go here

Вам нужно настроить свои IDE или скрипты сборки для размещения объектных файлов в /ProjectName/trunk/build/object (возможно, даже воссоздавая структуру каталогов под... /source ).

Таким образом, вы даете своим пользователям возможность проверить//имя_проекта/соединительную линию, чтобы получить полную среду здания, или /ProjectName/trunk/source, чтобы получить источник приложения.

В файле.. /build/bin и../build/lib вы должны поместить компиляторы и библиотеки, которые использовались для компиляции конечного продукта, те, которые использовались для отправки программного обеспечения пользователю. Через 5 или 10 лет вы будете иметь их там, доступных для вашего использования в некоторых случаях.

Ответ 5

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

Это хорошая идея для управления версиями, более конкретно для:

1/Проблема с упаковкой

Если артефакт сборки не просто exe (или dll или...), но также:

• некоторые файлы конфигурации
• некоторые скрипты для запуска/остановки/перезапуска артефакта
• некоторые sql для обновления базы данных
• некоторые источники (сжатые в файл) для облегчения отладки
• некоторая документация (сжатый файл javadoc в файле)

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

2/Проблема развертывания

Предположим, вам нужно развернуть множество артефактов в разных средах (тест, омологация, предварительная подготовка, производство).
Если:

• вы производите много артефактов сборки.
• эти артефакты довольно долго воссоздают с нуля

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

Но вам нужно помнить:

• 1/вы не можете хранить все артефакты, которые вы делаете в VCS: вся промежуточная сборка, которую вы создаете для непрерывной цели интеграции, должна содержать не в VCS (или вы получаете огромный репозиторий со множеством бесполезных версий двоичных файлов).
  Необходимо указывать только версии, необходимые для омологации и производства.
  Для промежуточной сборки вам нужен внешний репозиторий (maven или общий каталог), чтобы быстро публиковать/тестировать эти сборки.

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

Ответ 6

По моему опыту можно было хранить Jars в SVN в беспорядке.
Я думаю, что лучше сохранить Jar файлы в Maven-Repository, например Nexus.
Это также имеет преимущества, что вы можете использовать инструмент управления dependecy, например Maven или Ivy.

Ответ 7

Двоичные устройства, особенно ваши собственные, но также и сторонние, не имеют места в инструменте управления версиями, таком как SVN.

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

Для сторонних двоичных файлов вам понадобится инструмент управления зависимостями, например Maven2. Затем вы можете настроить локальный репозиторий Maven для обработки всех сторонних двоичных файлов (или просто полагаться на общедоступные). Местное репо также может управлять вашими бинарниками.

Ответ 8

Помещение двоичных файлов в багажник или ветки определенно переполняется. Помимо того, что вы занимаете место, как вы упомянули, оно также приводит к <сильным > несоответствиям между исходным кодом и двоичными файлами. Когда вы ссылаетесь на версию 1234, вы не хотите задаваться вопросом, означает ли это "сборка, полученная из источника в редакции 1234", и "двоичные файлы в редакции 1234". То же правило избежания несоответствий применяется к автоматически сгенерированному коду. Вы не должны использовать версию, которая может быть сгенерирована сборкой.

OTOH Я более или менее в порядке с размещением двоичных файлов в тегах. Таким образом, другим проектам легко использовать двоичные файлы других проектов через svn: externals, без необходимости создавать все эти зависимости. Он также позволяет тестировщикам легко переключаться между тегами без необходимости создания полной среды сборки.

Чтобы получить двоичные файлы в тегах, вы можете использовать эту процедуру:

• проверить чистую рабочую копию
• запустите конструкцию script и оцените результаты тестов
• если сборка в порядке, svn добавить двоичные файлы
• вместо того, чтобы переходить в багажник или ветку, тег непосредственно из вашего рабочая копия: svn copy myWorkingCopyFolder myTagURL
• отказаться от рабочей копии, чтобы избежать случайные фиксации двоичных файлов соединительная линия или ветка

У нас есть tagbuild script для полуавтоматизации этапов 3 и 4.

Ответ 9

Одна из веских причин - быстро запустить исполняемый файл на новой машине. В частности, если среда сборки требует времени для настройки. (Загружать компиляторы, сторонние библиотеки и инструменты и т.д.)

Ответ 10

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

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

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

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

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

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

Ответ 11

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

Ответ 12

Управление версиями должно иметь все, что вам нужно сделать: svn co, а затем построить. Он не должен иметь промежуточные продукты или конечный продукт, поскольку это побеждает цель. Вы можете создать новый проект в SVN для результата и версию двоичного результата отдельно (для выпусков и исправлений, если это необходимо).

Ответ 13

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

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

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

Адвокат на ежедневную автономную версию autobuild script, а не только на двоичные файлы + код

Ответ 14

• Subversion - это диспетчер управления версиями → Binaries не являются источниками
• Если вы используете команду "svn up" для обновления продукции, все разработчики с полномочиями фиксации могут обновлять/модифицировать/разорвать производство?

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

Ответ 15

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

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