Аргументы повторяют возврат двоичных файлов в SCM

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

Они знают, что это плохая практика, но они думают, что «это работает», и это на самом деле не проблема, даже когда многие люди знают о Maven и других инструментах для сборки помимо Ant. И PM, и программисты (около 50 человек) готовы выслушать любой аргумент против и даже признать, что это пустая трата места для резервного копирования, но я хочу быть действительно убедительным, потому что изменение привычки потребует больших усилий. Какие аргументы вы используете, чтобы поддержать изменение?

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

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

Вместо этого Вы можете обратиться к цели СКМ. Каждый файл, отслеживаемый SCM, представляет собой некоторую потребность в управлении параллельными распределенными изменениями, которые выполняет ваша команда. Ничто из этого не очевидно, пока два члена команды не попытаются изменить один и тот же файл. Решение этих изменений - это то, для чего на самом деле нужен SCM, предотвращая случайную перезапись работы другого разработчика и, надеюсь, автоматизируя процесс объединения этих изменений.

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

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

Для двоичных форматов, которые действительно представляют источники проекта, такие как художественные активы, это неудачный, но необходимый шаг. Однако выходные данные сборки не являются источниками. Нет необходимости объединять их, потому что источники могут быть объединены, и полученный результат сборки может быть восстановлен. Отслеживание и управление этими изменениями - это 100% отходов. Он тратит ресурсы SCM, хотя и не так сильно, но также тратит время разработчика на преодоление ложных слияний. Время разработки очень дорого, и все, что тратит его впустую, является раком.

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

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

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

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

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

Почти никто не делает это.

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