методы, чтобы хранить двоичные файлы в SVN

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

См. Настройка производительности Subversion .

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

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

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

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

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

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

Правка : Позвольте мне подчеркнуть, что я имею в виду под COMMIT и IMPORT.

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

IMPORT, с другой стороны, импортирует новый файл, как если бы вы только что дали ему новый файл и сказали «забудьте о предыдущий, просто сохраните этот файл », и, таким образом, на проработку различий не будет тратиться время или память, но результирующий набор изменений в репозитории будет больше. Другими словами, дисковое пространство на вашем сервере Subversion будет затронуто больше, чем команда COMMIT, но IMPORT обычно выполняется намного быстрее.

Любой другой рабочий процесс, который вы хотите наложить, должен выполняться вне Subversion. Сюда входят команда TAR и параметры сжатия, доступные в вашей операционной системе. Если вы хотите использовать «метод 1», вы сами должны вручную сжать файл (ы), который вы хотите импортировать, в один файл .tar перед тем, как передать его Subversion. Вы не можете просить Subversion сделать это за вас. Вы, конечно, можете создавать файлы сценариев, которые в некоторой степени автоматизируют процесс, но все же это не проблема Subversion.

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