Это возможно, но не обязательно просто: проблема, которую вы пытаетесь решить это опасно близко к созданию распределенной среды разработки, которая является не то, что SVN является предназначен для.
СВН-зеркало способ
Вы можете использовать svn mirror, как описано в книге документации SVN для создания только для чтения зеркало вашего главного репозитория. Ваши разработчики взаимодействуют с ближайшим к ним зеркалом. Однако пользователи хранилища ведомой придется использовать
СВН переключатель --relocate master_url
, прежде чем они могут совершить, и они должны помнить, чтобы переехать обратно на ведомом только они сделаны. Это можно было бы автоматизировать с использованием сценария обертки вокруг команд модификации репозитория в SVN, если вы используете клиент командной строки. Имейте в виду, что операция переместить в то время как быстро добавляет немного накладных расходов. (И будьте осторожны, чтобы дублировать хранилище UUID - см. the SVN documentation)
[Edit - Проверка TortoiseSVN документации, кажется, что вы можете иметь TortoiseSVN execute hook scripts client side. На этом этапе вы сможете создать сценарий pre/post commit. Либо это, либо попытайтесь увидеть, можете ли вы использовать TortoiseSVN automation interface, чтобы сделать это].
СВК путь
svk представляет собой набор скриптов на Perl, которые имитируют распределенный сервис зеркалирования через SVN. Вы можете настроить его так, чтобы локальная ветвь (зеркало) делилась несколькими разработчиками. Тогда базовое использование для разработчиков будет полностью прозрачным. Вам нужно будет использовать клиент svk для сбора, сливания и starmerging. Это выполнимо, если вы можете сосредоточиться на распределенных концепциях.
мерзавец-Svn путь
В то время как я никогда не использовал это сам, вы также могли бы далекие разработчики используют Git локально и использовать git-svn шлюз для синхронизации.
Заключительные слова
Все зависит от вашей среды разработки и уровня интеграции вам требуется. В зависимости от вашей IDE (и если вы можете изменить SCM), возможно, вам захочется взглянуть на другие полностью распределенные SCM (думаю, Mercurial/Bazaar/Git/...), которые поддерживают распределенную разработку из коробки.
Я скептически, как проксирование может улучшить ситуацию. Возможно, фиксация занимает меньше времени для POV пользователя, но данные все равно должны быть переданы ведущему устройству, и это по-прежнему занимает примерно столько же пропускной способности сети. Таким образом, обновление мастера происходит так же медленно, даже если оно появляется быстрее для пользователя. Из-за этого асинхронного поведения мастер может начать отставать. – aseq 2012-08-09 00:16:47