Как преобразовать существующий каталог в рабочую копию SVN (WC) без замены локальных файлов?

Question

У меня большой репозиторий Subversion с почти 15 ГБ данных, распределенных по ~ 500 000 файлов. Теперь мне нужно проверить этот репозиторий на удаленном хосте, что может занять несколько дней.

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

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

Answer 1

Начиная с версии SVN 1.7 (но не раньше) вы можете легко это сделать с помощью:

svn co --force http://path/to/repo

Это будет относиться к локальной копии как существующей, и перед каждым именем файла в выходных данных вы увидите «E» для существующих: E some/existing/file

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

До версии 1.7 Subversion по умолчанию жаловалась, если вы пытаетесь извлечь каталог поверх существующего каталога, который содержит файлы или подкаталоги, которые создала бы сама касса. Subversion 1.7 обрабатывает эту ситуацию по-другому, позволяя продолжить извлечение, но помечая любые препятствующие объекты как конфликты деревьев. Используйте параметр --force, чтобы переопределить эту защиту. Когда вы используете опцию --force, любой неверсионный файл в дереве целей извлечения, который обычно препятствует извлечению, все равно станет версионным, но Subversion сохранит его содержимое как есть. Если это содержимое отличается от файла репозитория по этому пути (который был загружен как часть проверки), файл будет иметь локальные изменения - изменения, необходимые для преобразования проверенного версионного файла в неверсионный файл, который вы имели до проверки out - когда проверка завершена.

Также обратите внимание, что SVN 1.7 может привести к ситуациям, когда это более распространенная проблема (возможно, мотивация решения). Я столкнулся с этой проблемой при перемещении каталога sub в новое место на диске. В pre-1.7 это переместило бы каталог .svn вместе с ним, и оно бы прекрасно работало в одиночку. В 1.7 каталог стал практически не версионным. Но svn co --force спас день.

Answer 2

Существует команда перемещения: http://svnbook.red -bean.com / ru / 1.1 / re27.html

EDIT: Если локальные файлы не связаны с репозиторием, вы можете создать локальный репозиторий, импортировать в него файлы и затем использовать команду relocate.

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

Answer 3

svn co --force https://PATH/TO/REPO/ .

Где . в конце предполагает, что вы уже находитесь в каталоге, который вы хотите превратить в рабочую копию SVN.

Например, если вы хотите сделать каталог public_html рабочей svn-копией репозитория:

cd /home/username/public_html; svn co --force https://PATH/TO/REPO/ .

Answer 4

Следующая команда предназначена для удаления всех каталогов .svn.

chmod -R 0755 project_dir
find /project_dir -type d -name .svn -exec rm -rf '{}' +

Если у вас уже есть версия оформления заказа, вы можете попробовать скопировать эти папки .svn, заменив rm на cp. Хотя я не пытался.

Answer 5

Вы можете попробовать использовать rsync, если у вас уже есть рабочая копия под управлением svn где-то еще в сети.

Answer 6

У меня был рабочий репозиторий на локальном компьютере, который удалял все свои папки .svn при сбое Eclipse.

Единственный способ, которым я смог подключить его к удаленному SVN-репозиторию, - это выполнить эти шаги в блоге, который я нашел ( Восстановление сломанной рабочей копии Subversion ):

# Backup your project in case you run into trouble
cp -Rp /path/to/project /temporary/location

# Strip out the old .svn folders (if any)
find /path/to/project -name .svn -print0 | xargs -0 rm -rf

# Check out a clean copy
svn co http://repo/location /temporary/location2

# Move the .svn folders from the clean copy into the correct relative
# place in the broken copy
cd /temporary/location2
find . -name .svn -print0 | xargs -0 -I {} mv '{}' '/path/to/project/{}'

# Remove the clean copy
rm -rf /temporary/location2

Answer 7

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

Используйте Subversion 1.7, таким образом, нет .svn с нетронутыми копиями файлов.

Answer 8

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

Какой протокол вы используете для доступа к хранилищу? Если это https, это может быть вашей проблемой. Попробуйте собственный протокол svn (используя svnserve) или svn + ssh. Или, возможно, даже выполните проверку через файл: // URL на сервере, на котором размещено хранилище svn, и затем используйте rsync для передачи по сети.

Пока вы не платите за пропускную способность на байт, возможно, имеет смысл разрешить "svn co --force" работать под управлением nice или (START / LOW в Windows) и тратить свое время. Это не сделает ничего в локальной файловой системе недоступным во время процесса извлечения.

Наконец, я не могу понять, почему ваша проверка происходит так медленно ... у нас есть хранилища файлов размером 500 КБ, которые извлекаются через ~ 6 минут через https в гигабитной локальной сети. Конечно, все файлы намного меньше (всего 1 ГБ). Как далеко от сервера вы находитесь с точки зрения задержки?

Answer 9

Я не верю, что есть решение без переноса этих 15 ГБ в место назначения. Вероятно, было бы быстрее и проще скопировать туда хранилище и выполнить локальную проверку.

Answer 10

Вы можете просто извлечь хранилище локально, а затем передать только каталоги .svn (осторожно, они содержат копии файлов рабочей области, очевидно, вы не хотите их копировать). Это должно сработать, поскольку у вас будут точные файлы правильной рабочей копии.

Конечно, вам нужно написать какой-нибудь скрипт для передачи файлов .svn. В системе Unix вы можете сделать это с помощью find и друзей.