SVN Перемещение или переключатель?

Ответ 1

EDIT. Основываясь на вашем выводе выше, я думаю, вам нужно использовать другой подход. Похоже, что исходный репозиторий был создан как /data/repository с папкой с именем DDL2 в репозитории. Это можно увидеть, глядя на значение "Корневого хранилища" вашей рабочей копии.

Вы не сможете просто вывести корень репозитория вниз с помощью svn switch. Вместо этого вам нужно будет использовать svn move для реорганизации вашего репо вокруг нового нужного корня. Это означает, что вы будете продолжать выполнять свое репо с /data/repository, но переместите все файлы под DDL2 на верхний уровень.

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

Ответ 2

Этот вопрос имеет ответ. В частности:

svn switch --relocate http://svn.example.com/path/to/repository/path/within/repository http://svnnew.example.com/new/repository/path/within/repository

Ответ 3

Перемещение используется, если вы планируете переключать серверы. Например, если вы хотите, чтобы рабочая копия больше не ссылалась на svn://192.168.1.35/DDL2/trunk/DD_L2DP в пользу svn://192.168.1.127/DDL2/trunk/DD_L2DP, вы должны использовать перемещение.

Коммутатор используется, если вы хотите изменить каталог в репозитории, на который ссылается ваша рабочая копия. Я считаю, что это так, как вы хотите. Эта операция не влияет на номер ревизии репозиториев: она обновляет только URL рабочей копии.

svn move используется, если у вас есть svn://192.168.1.35/trunk/DDL2DP, и вы хотите создать svn://192.168.1.35/DD_L2DP/trunk, но он еще не существует в вашем репозитории.

Ответ 4

switch (sw): Update the working copy to a different URL.
usage: 1. switch URL[@PEGREV] [PATH]
       2. switch --relocate FROM TO [PATH...]

  1. Update the working copy to mirror a new URL within the repository.
     This behavior is similar to 'svn update', and is the way to
     move a working copy to a branch or tag within the same repository.
     If specified, PEGREV determines in which revision the target is first
     looked up.

     If --force is used, unversioned obstructing paths in the working
     copy do not automatically cause a failure if the switch attempts to
     add the same path.  If the obstructing path is the same type (file
     or directory) as the corresponding path in the repository it becomes
     versioned but its contents are left 'as-is' in the working copy.
     This means that an obstructing directory unversioned children may
     also obstruct and become versioned.  For files, any content differences
     between the obstruction and the repository are treated like a local
     modification to the working copy.  All properties from the repository
     are applied to the obstructing path.

     Use the --set-depth option to set a new working copy depth on the
     targets of this operation.  Currently, the depth of a working copy
     directory can only be increased (telescoped more deeply); you cannot
     make a directory more shallow.

  2. Rewrite working copy URL metadata to reflect a syntactic change only.
     This is used when repository root URL changes (such as a scheme
     or hostname change) but your working copy still reflects the same
     directory within the same repository.