наилучшая практика хранения не исходных файлов под контролем версий

Question

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

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

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

Answer 1

У меня есть много не исходных файлов в SVN, и единственный раз, когда он замедляет фиксацию, это когда я их изменяю. Я не понимаю, как это проблема, если они меняются только «часто». Также размер действительно не должен быть проблемой. Если ваш репозиторий находится на сервере, и вы беспокоитесь о том, сколько места он занимает, вам необходимо выполнить обновление. Жесткие диски дешевые. Купи их.

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

Answer 2

Вы добавили в комментарии:

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

Это означает, что у вас есть линейный рабочий процесс разработки, работающий только на ПОСЛЕДНЕМ из одной основной ветви.
Похоже, вы не имеете дела с фазой «после релиза», когда вам нужно:

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

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

В любом случае, если вы чувствуете, что SVN не обрабатывает их должным образом, я все равно рекомендовал бы иметь какой-то способ запомнить, что для версии SVN от xxx до yyy вы использовали версию 'z' вашего набора двоичных файлов. Для этого вы можете настроить внешний репозиторий, например Maven . См. Вопрос « Допустимо ли / полезно ли хранить двоичные файлы в SVN? » (мой ответ на этот вопрос находится в верхней части страницы, но я прямо ссылаюсь на ответ Эвана, когда он упоминает о Maven).

Answer 3

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

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