Вы не устанавливаете Subversion для использования любого из этих методов, вы указываете, какой метод использовать при помещении файлов в хранилище. И под «методом» я не подразумеваю ни одну из четырех упомянутых вами, а просто «импорт» или «фиксация», и вам придется постоянно рассказывать Subversion о методе, выбранном каждый раз, когда вы хотите сохранить новый ревизия этого файла в хранилище.
См. Настройка производительности Subversion .
Как вы можете видеть из описания там, чтобы использовать «метод 1», сжимая в tar и затем использовать import, они должны сами сжать все двоичные файлы в файл .tar, а затем использовать команду import Subversion для добавления файлов в хранилище.
Также обратите внимание, что предостережение: команда импорта хранит файлы как новые файлы, а не как разногласия с предыдущей ревизией, поэтому она может быть экономичной по времени, но не компактной, если было зафиксировано несколько изменений в большом файле. .
Subversion сама по себе только фиксирует и импортирует. Фиксация - это новая ревизия существующего файла, хранящаяся в виде последовательности дельт (или первой ревизии нового файла, которой нет), а импорт - это просто новый файл. Все остальное, что вам придется сделать самостоятельно.
Если бинарные файлы изменяются только время от времени, возможно, стоит обратить на них больше внимания, но если они регулярно меняются, я бы предложил просто использовать Subversion как обычно с командой commit.
Также обратите внимание, что типичным советом, когда речь идет о двоичных файлах, является то, что вместо двоичного файла вы сохраняете исходный код во все, что создает эти двоичные файлы, если это возможно, а затем повторно запускаете инструменты для воспроизведения актуальные бинарные файлы. Если двоичные файлы требуют времени или пространства для воспроизведения, только тогда вы также сохраняете эти двоичные файлы.
Проблема заключается в том, что двоичные файлы не очень хороши для сравнения, и, таким образом, если разработчик a и b оба извлекают последнюю версию, а затем разработчик a фиксирует новую версию, прежде чем разработчик b попытается сделать то же самое, возникнет конфликт произойдет. Разработчик B может остаться без выбора, кроме как попытаться выяснить изменения самостоятельно.
Редактировать : Позвольте мне подчеркнуть, что я имею в виду под COMMIT и IMPORT.
Основное отличие состоит в том, что COMMIT, если у вас уже есть файл в репозитории, попытается сравнить файл в вашей рабочей копии с предыдущей версией репозитория и сохранить только изменения. Это потребует времени и памяти, чтобы отработать эти различия, но, как правило, приведет к небольшой ревизии изменений в вашем хранилище. Другими словами, дисковое пространство на вашем сервере Subversion будет меньше затронуто, чем с помощью команды IMPORT.
ИМПОРТ, с другой стороны, будет импортировать новый файл, как если бы вы просто дали ему новый файл и сказали «забудь о предыдущем, просто сохрани этот файл», и, таким образом, на работу не уйдет ни времени, ни памяти. различия, но результирующий набор изменений в хранилище будет больше. Другими словами, дисковое пространство на вашем сервере Subversion будет затронуто больше, чем с помощью команды COMMIT, но IMPORT, как правило, будет работать намного быстрее.
Любой другой рабочий процесс, который вы хотите навязать, должен выполняться вне Subversion. Это включает команду TAR и параметры сжатия, доступные в вашей операционной системе. Если вы хотите использовать «метод 1», вы сами должны вручную сжать файлы, которые хотите импортировать, в один файл .tar, прежде чем передать его в Subversion. Вы не можете попросить Subversion сделать что-нибудь для вас. Конечно, вы можете создавать файлы сценариев, которые несколько автоматизируют процесс, но, тем не менее, это не проблема Subversion.
Я бы сделал несколько серьезных тестов с этим, чтобы выяснить, действительно ли выгоды стоят дополнительной работы, которую вы налагаете на ваш рабочий процесс Subversion.