Мы хотели бы поделиться двоичными файлами проекта runtime. Поэтому каждый член команды может принять текущую рабочую версию. Допустимо/полезно сохранять исполняемые файлы в SVN?
Является приемлемым/хорошим для хранения двоичных файлов в SVN?
Ответ 1
Две общие причины, по которым вы захотите сохранить двоичные файлы в системе управления версиями, написаны в 2009 году:
- хранить внешние сторонние библиотеки.
Обычно они хранят их в репозитории Maven, но для их хранения в SVN вы можете иметь один и только один ссылочный для всех ваших потребностей: получить свои источники и получить свои библиотеки, необходимые для компиляции этих источников, Все происходит из одного хранилища.
(Как отмечено ivorujavaboy в 2017 году: "Единственная веская причина сделать это в настоящее время - это если у вас есть библиотеки STATIC, которые никогда не изменятся, что это действительно редкий случай" )
- хранить поставки для более быстрого развертывания.
Обычно поставки (исполняемый файл, который вы создаете для развертывания в производство) строятся по требованию. Но если у вас много предпроизводственной среды, и если у вас много поставок, стоимость их сборки для сборки, интеграции, омологации, предпроизводственных платформ может быть высокой.
Решение состоит в том, чтобы построить их один раз, сохранить их в разделе доставки вашего SVN и использовать их непосредственно в вашей другой среде.
Примечание:
Это также относится к элементам разработки: если у вас есть Jaxb процесс, который генерирует 900 POJO файлов (посредством привязки XML), и вам нужно загрузите этот набор для разработки в нескольких средах, вам может понадобиться 1 сжатая транзакция копирования файла, а не 900.
Итак, "приемлемо/хорошо хранить исполняемые файлы в SVN"... по правильным причинам.
Сказанное:
- Wim Coenen по праву упоминает недостатки (плохая практика, медленное, несоответствие между источниками и сохраненной доставкой)
- Vladimir выступает за использование справочной информации (Nexus или, как упоминает Владимир, Apache ivy)
- RogerV иллюстрирует преимущества использования указанной ссылочной ссылки (Nexus в своем случае)
Ответ 2
Нет, не храните двоичные файлы рядом с их исходным кодом (если у вас нет веских причин, которые компенсируют недостатки).
Недостатки:
- он поощряет плохие методы сборки в крупных проектах. Лучшая практика - полностью автоматизировать вашу сборку. Комбинированные двоичные файлы позволяют игнорировать это: "просто вручную выполните сборку для частей, которые изменились": - (
- медленнее обновлений и совершает
- фиксирует изменение исходного кода, но не соответствующие бинарные файлы вызовут путаницу среди разработчиков. Как вы обнаруживаете несоответствие?
-
svn updateобновит временную метку ваших двоичных файлов, запутав ваши инструменты сборки, которые ошибочно считают, что двоичные файлы новее, чем изменения исходного кода. - вызывает ложные конфликты для двоичных файлов для
svn updateиsvn merge - он использует больше места на диске в репозитории. (Это может быть незначительным в зависимости от вашего проекта.)
В общем, избегайте совершать то, что генерируется автоматически детерминированным способом из других версий. Нет избыточности → нет возможности для несоответствий.
Вместо этого используйте сервер непрерывной интеграции для автоматической перестройки (и запуска тестов) для каждой фиксации. Пусть этот сервер сборки публикует двоичные файлы где-нибудь (вне SVN), если это необходимо.
Теперь это не означает, что вы должны считать это абсолютным правилом или избегать всех двоичных файлов. Во что бы то ни стало, поместите свои инструменты сборки и сторонние двоичные файлы с закрытыми исходными кодами в свои проекты. И делайте исключения, когда это имеет смысл. В идеале новый разработчик должен иметь возможность выполнить проверку и сразу же запустить сборку script, не потратив ни дня, ни дня на создание своей среды.
Ответ 3
Я бы сказал, что если это облегчит вашу команду, сделайте это. Если это уменьшает время, затраченное на создание рабочей среды разработки, заходите на это.
Ответ 4
Как уже говорилось, это приемлемо.
Да, удобно иметь все удобное из одного места, откуда вы можете (например) проверить старый тег уже в двоичной форме с его правильными зависимостями.
Но это НЕ хорошо, особенно для целей резервного копирования. Мы сохранили все наши двоичные файлы (и часть зависимостей) в SVN и по мере того, как проект рос, так что двоичный раздел сделал.
К сожалению, svnadmin dump просто сбрасывает все, вы не можете указать путь для исключения репозитория. Таким образом, резервные копии (и обновления сервера svn) стали очень болезненными!
Если вы добавите, что после недолгого времени в нашем случае эти двоичные файлы больше не были полезны, я уверен, что я не буду делать это снова в аналогичном случае (но я бы сделал для меньшего проекта).
Поэтому я бы рекомендовал дважды подумать, прежде чем делать это, и попытаться предсказать, насколько велика вы можете расти и что еще может произойти.
Ответ 5
Не для этой цели нет. Вы должны использовать внешний хранилище файлов, например FTP или веб-сервер. Таким образом, вы можете легко загрузить определенную версию своего двоичного файла без обновления для этой версии в SVN.
Ответ 6
Всякий раз, когда я вижу библиотеку в каталоге Subversion, я задаю следующие вопросы:
- какая версия? (обычно у вас есть
axis.jar, а неaxis-1.4.jar) - почему он был включен? (особенно сложно с зависимостями зависимостей)
Если у вас нет системы управления зависимостями, вы обычно не можете отвечать на оба вопроса. И это первый шаг к Jar Hell.
Я могу порекомендовать Apache Ivy (другие могут ругаться Maven) с реестром интрасети. Используя Ivy, мне никогда не приходилось хранить библиотеки в SVN и всегда могли отвечать на вышеупомянутые вопросы.
Ответ 7
Да, сохраните его.
Мы использовали для хранения двоичных файлов, которые мы доставляли клиентам в репозитории SVN, чтобы отслеживать его.
Также другое использование хранения двоичных файлов в SVN (или контроле источника) заключается в том, что вы предоставляете некоторые внутренние служебные модули другим командам вашей компании, которые не хотят строить ваш проект, чтобы сохранить время сборки. Я считаю, что это обычная практика.
Но нам никогда не разрешалось хранить файлы .classpath и .project Eclipse (связанные с рабочей средой настройки).
Ответ 8
Наши сборники Java.jar были привязаны в зависимостях файлов .jar, которые мы проверяли на svn. На практике это было избыточно, но мы хотели обеспечить, чтобы каждая сборка Java-приложений, которую мы производили, имела именно те библиотеки, в которые она подвергалась QA.
Что действительно меня усугубило, тем не менее, с таким подходом я начал делать удаленные подключения к репозиторию и синхронизацию. Навсегда оставалось бы просто перебирать все двоичные библиотеки.
Мы с тех пор отказались от этой практики и теперь используем Maven для управления зависимостями библиотек - даже для проектов, которые мы все еще строим с помощью ant. В svn не проверяется больше двоичных файлов. Из-за этого сдвига стратегии жизнь намного лучше на нескольких фронтах. И у нас есть строгий контроль над версиями зависимостей библиотек, которые мы желали.
Для наших сборников .NET один из моих разработчиков разработал решение, которое работает в значительной степени подобно Maven по отношению ко всему материалу управления зависимостями и приносит тоже много пользы.
Ответ 9
Если вы разрабатываете Java, вы можете настроить локальный репозиторий , а затем использовать инструмент, например maven или ivy + ant для доступа к ней.
Вы можете загружать обновления локальных артефактов сборки обратно в локальный репозиторий, поскольку они готовы для других пользователей компании.
В других средах разработки я не знаю, какие инструменты, подобные приведенным выше, доступны - я, как правило, просто помещал их в SVN и делал с ним.
Обычно я использую отдельный репозиторий для хранения сторонних библиотек, чтобы они не попадали в обычные репозитории разработки, и мои файлы сборки загружают их в ожидаемое местоположение относительно базовой папки проекта.
Собственно, я использую два репозитория. Один для минимальных файлов, которые мне нужны для создания моих проектов (например, jar, lib файлов) и другого для всего стороннего пакета (включая источник, документацию или что-то еще), который я обычно храню tar.bz2.
Таким образом, если вы просто хотите получить минимум, необходимый для создания материала, вы захватите первый репозиторий, и если вам нужно выяснить, что происходит, или как использовать сторонний пакет, вы можете начните вытаскивать материал из второго хранилища.
Это не идеальное решение, но оно работает очень хорошо.
Здесь есть дополнительная информация о том, как svn обрабатывает двоичные файлы.
Ответ 10
Это прекрасно и приемлемо хранить двоичные файлы в SVN-репо. В качестве побочного элемента я не понимаю, почему кто-то хочет хранить сборку артефактов в репозитории (я не говорю, что вы это делаете).
Ответ 11
Я бы позволил моей системе построения и непрерывной интеграции обрабатывать новейшую рабочую версию, автоматически копируя их на FTP, веб-или общий доступ к файлам для легкого доступа.
Еще лучше я бы инвестировал в CI-систему, которая автоматически обрабатывает артефакты сборки, я люблю TeamCity от самих jetbrains, но есть другие, Таким образом вы можете полностью обрабатывать его.
Ответ 12
Сохранение двоичных файлов при управлении версиями, возможно, приводит к нарушению цели контроля версий. Вам лучше использовать HTTP/FTP. Это обсуждение SO на https://stackoverflow.com/questions/104453/version-control-for-binaries может быть полезно!
Ответ 13
Храните двоичные файлы, которые не все могут создать. Я разрабатываю чипы в Verilog и VHDL, и у команды разработчиков нет этих инструментов. Таким образом, мы сохраняем выходные двоичные файлы в SCM.
Ответ 14
Есть некоторые утверждения по этому вопросу, но я говорю "да".
Ответ 15
По крайней мере, я храню двоичные файлы в SVN, таким образом, я могу быстро вернуться к конкретному бинарному варианту и посмотреть, произошла ли ошибка в нем или нет, и проследить версию, где была введена ошибка, а затем проверить весь проект, настройте все конкретные связанные с проектом и настройки среды, а затем скомпилируйте его.