Вы не устанавливаете Subversion для использования любого из этих методов, вы указываете, какой метод следует использовать при помещении файлов в репозиторий. И «методом» я не имею в виду ни один из упоминаемых вами 4, а скорее просто «импорт» или «фиксация», и вам придется постоянно сообщать Subversion о выбранном методе каждый раз, когда вы хотите сохранить новый пересмотр этого файла в репозиторий.
См. Performance tuning Subversion.
Как вы можете видеть из описания там, чтобы использовать «метод 1», сжимаясь до tar, а затем использовать импорт, им приходится сжимать все двоичные файлы в .tar-файл, а затем использовать импорт команда Subversion для добавления файлов в репозиторий.
Также обратите внимание, что в этом случае команда импорта хранит файлы в виде новых файлов, а не как дельта для предыдущей версии, поэтому она может быть эффективной с точки зрения времени, но не пространственно эффективной, если мало изменений в большом файле совершено.
Subversion сам по себе совершает и импортирует. Конец - это новая редакция существующего файла, хранящаяся как последовательность дельт (или первая ревизия нового файла, а это не так), а импорт - это просто новый файл. Все, что вам нужно сделать самому.
Если бинарные файлы изменяются только сейчас, то это может стоить больше внимания, но если они меняются регулярно, я бы предложил просто использовать Subversion как обычно, с командой commit.
Также обратите внимание, что типичный совет, когда речь заходит о двоичных файлах, заключается в том, что вместо двоичного файла вы храните исходный код в том виде, в котором оно есть, что дает, по возможности, эти двоичные файлы, а затем повторно запускает инструменты для воспроизведения фактические двоичные файлы. Если двоичные файлы являются временными или объемными для воспроизведения, только тогда вы также храните двоичные файлы, о которых идет речь.
Двоичные файлы имеют проблему не очень хорошего сравнения, и, таким образом, если разработчик a и b извлекает последнюю версию, а затем разработчик совершает новую ревизию до того, как разработчик b попытается сделать то же самое, некоторый тип конфликт будет происходить. Разработчик B может остаться без опции, но попытаться самостоятельно выяснить изменения.
Edit: Позвольте мне подчеркнуть, что я имею в виду COMMIT и IMPORT.
Главное отличие состоит в том, что COMMIT будет, если у вас уже есть файл в репозитории, попробуйте разбить файл в рабочей копии на предыдущую версию репозитория и сохранить только изменения. Для выработки этих различий потребуется время и память, но обычно это приведет к небольшому ревизионному набору изменений в вашем репозитории. Другими словами, дисковое пространство на вашем сервере Subversion будет меньше влиять, чем на команду IMPORT.
IMPORT, с другой стороны, импортирует новый файл, как если бы вы только что дали ему новый файл, и сказали: «Забудьте о предыдущем, просто сохраните этот файл», и, таким образом, время и память не будут потрачены на разыгрывая различия, но полученный набор изменений в репозитории будет больше. Другими словами, дисковое пространство на вашем сервере Subversion будет больше влиять, чем на команду COMMIT, но IMPORT будет работать намного быстрее.
Любой другой рабочий процесс, который вы хотите наложить, должен выполняться вне Subversion. Сюда входят команды TAR и параметры сжатия, доступные в вашей операционной системе. Если вы хотите перейти к «методу 1», вам придется вручную сжать файлы, которые вы хотите импортировать, в один файл .tar, прежде чем передавать его в Subversion. Вы не можете просить Subversion сделать что-либо из этого для вас. Конечно, вы можете создавать файлы сценариев, которые несколько автоматизируют процесс, но тем не менее это не проблема Subversion.
Я бы сделал несколько серьезных тестов с этим, чтобы выяснить, действительно ли выигрыш стоит дополнительной работы, которую вы наложите на рабочий процесс Subversion.
Вы говорите, что только 2 варианта: IMPORT и COMMIT? и что у Импорта есть возможность импортировать сжатый файл tar (сжатый ручной) или обычные файлы? , который один из 3 эффективен по времени? thanks :) – Oded
IMPORT импортирует все, что вы ему даете, будь то оригинальный файл, tar-файл, файл gzip, zip-файл, rar-файл, что угодно. COMMIT. Разница заключается в том, что COMMIT попытается разбить файл на предыдущую ревизию репозитория, тогда как IMPORT не будет, поэтому он будет быстрее, но займет больше места, если на самом деле произойдут изменения в предыдущей редакции, в отличие от радикального нового содержимого файла , –
Думаю, теперь я понимаю. Есть ли в VisualSVN, возможно, я могу настроить хранилище mothod для двоичных файлов или нет такой опции, но делать это вручную или писать скрипты? – Oded