Приемлемо / хорошо ли хранить бинарные файлы в SVN?

Question

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

Answer 1

Две распространенные причины, по которым вы можете захотеть хранить двоичные файлы в системе контроля версий: (написано в 2009 году):

• хранить внешние сторонние библиотеки .
  Обычно их хранят в репозитории Maven, но их хранение в SVN позволяет вам иметь один и только один ссылочный для всех ваших нужд: получить источники и получить свои библиотеки нужно скомпилировать эти источники. Все приходит из одного хранилища.

(Как отметил ivorujavaboy в 2017 году: «Единственная веская причина сделать это в настоящее время, если у вас есть STATIC библиотеки, которые никогда не изменятся, что является действительно редким случаем»)

• хранить поставки для более быстрого развертывания .
  Обычно поставки (исполняемый файл, который вы создаете для развертывания в рабочей среде) создаются по требованию.
  Но если у вас много предсерийных сред и если у вас много поставок, стоимость их сборки для сборки, интеграции, омологации, предсерийных платформ может быть высокой.
  Решение состоит в том, чтобы создать их один раз, сохранить их в разделе поставок SVN и использовать их непосредственно в другой среде.
  Примечание:
  Это относится и к элементам разработки: если у вас есть процесс Jaxb , который генерирует 900 файлов POJO (посредством привязки XML), и вам необходимо загрузить этот набор разработки в нескольких средах, вам может потребоваться 1 транзакция копирования сжатого файла , а не 900.

Так что да, "допустимо / хорошо хранить исполняемые файлы в SVN" ... по правильным причинам.

---

Как говорится:

• Вим Коенен справедливо упоминает недостатки (плохая практика, медленный, несоответствие между источниками и сохраненной доставкой)
• Владимир выступает за использование референтной ссылки доставки (Nexus или, как упоминает Владимир, Apache ivy )
• RogerV иллюстрирует преимущества использования упомянутой ссылки доставки (Nexus в его случае)

Answer 2

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

Недостатки:

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

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

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

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

Answer 3

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

Answer 4

Как уже говорили многие, это приемлемо.

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

Но это НЕ хорошо, особенно для целей резервного копирования. Мы сохранили все наши двоичные файлы (и часть зависимостей) в SVN и по мере развития проекта, так что бинарный раздел сделал.

К сожалению, svnadmin dump просто сбрасывает все, вы не можете указать путь к репозиторию, который нужно исключить. Таким образом, резервные копии (и обновления сервера SVN) стали очень болезненными!

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

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

Answer 5

Не для этого, нет. Вам следует использовать внешнее хранилище файлов, такое как FTP или веб-сервер. Таким образом, легко загрузить определенную версию вашего исполняемого двоичного файла без необходимости сначала обновлять эту версию в SVN.

Answer 6

Всякий раз, когда я вижу библиотеку в каталоге Subversion, я задаю следующие вопросы:

• какая это версия? (обычно у вас есть axis.jar, а не axis-1.4.jar)
• почему это было включено? (особенно сложно с зависимостями зависимостей)

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

Я могу порекомендовать Apache Ivy (другие могут поклясться Maven) с внутренним хранилищем. Используя Ivy, мне никогда не приходилось хранить библиотеки в SVN, и я всегда мог ответить на вышеупомянутые вопросы.

Answer 7

Да, храните его.

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

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

Но мы никогда не позволяли хранить файлы .classpath и .project в Eclipse (настройки, связанные с рабочим пространством).

Answer 8

Если вы разрабатываете на Java, вы можете настроить локальный репозиторий , а затем использовать такой инструмент, как maven или ivy + муравей для доступа к нему.

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

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

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

На самом деле, я использую два хранилища. Один для минимальных файлов, которые мне нужны для сборки моих проектов (например, jar, lib files), а другой для всего стороннего пакета (включая исходный код, документацию или что-то еще), который я обычно храню tar.bz2.

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

Это не идеальное решение, но оно работает довольно хорошо.

Здесь - дополнительная информация о том, как svn обрабатывает двоичные файлы.

Answer 9

Наши сборки файлов Java .jar были привязаны к их зависимостям файлов .jar, которые мы проверяли в svn. Многое из этого было на практике избыточно, но мы хотели обеспечить, чтобы каждая сборка Java-приложения имела именно те библиотеки, с которыми она прошла QA.

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

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

Для наших сборок .NET один из моих разработчиков разработал решение, которое в значительной степени работает, как Maven, по всем аспектам управления зависимостями, и в этом тоже добивается такого же преимущества.

Answer 10

Храните двоичные файлы, которые не каждый может создать. Я разрабатываю чипы в Verilog и VHDL, и у команды разработчиков нет этих инструментов. Поэтому мы храним выходные двоичные файлы в SCM.