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

Я переустановил мой SVN-сервер, и путь изменился с svn://192.168.1.35/DDL2/trunk/DD _... на svn://192.168.1.35/trunk/DD _.... Я сделал несколько изменений в рабочей копии и хочу зафиксировать ее на сервере, поэтому мне нужно изменить путь /url, не затрагивая рабочую копию.

Я попытался использовать функцию TortoiseSVN Relocate, но получил "Relocate может изменить только часть репозитория URL-адреса", возможно, я должен использовать Switch, но я беспокоюсь о пересмотре рабочей копии.

svn info svn://192.168.1.35/

Path: 192.168.1.35
URL: svn://192.168.1.35
Repository Root: svn://192.168.1.35
Repository UUID: 259834e4-a888-4201-9858-aaacfe621d8e
Revision: 58
Node Kind: directory
Last Changed Author: rize
Last Changed Rev: 58
Last Changed Date: 2009-11-02 18:33:09 +0100 (po, 02 11 2009)

svn info D:\Programy\Eclipse Workspace\LDD_L2DP

Path: D:\Programy\Eclipse Workspace\LDD_L2DP
URL: svn://192.168.1.35/DDL2/trunk/DD_L2DP
Repository Root: svn://192.168.1.35
Repository UUID: 259834e4-a888-4201-9858-aaacfe621d8e
Revision: 21
Node Kind: directory
Schedule: normal
Last Changed Author: rize
Last Changed Rev: 17
Last Changed Date: 2009-10-21 19:22:41 +0200 (st, 21 10 2009)

Старая структура:

svn://192.168.1.35/DDL2
svn://192.168.1.35/DDL2/trunk/DD_L2DP

Новая структура

svn://192.168.1.35/
svn://192.168.1.35/trunk/DD_L2DP

Ответ 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.