SVN重新定位还是切换？

我已重新安装我的SVN服务器，路径已从svn://192.168.1.35/DDL2/trunk/DD_... 到svn://192.168.1.35/trunk/DD_... . 我对工作副本做了一些更改，并希望在服务器上提交它，因此我需要在不影响工作副本的情况下更改路径/url

我曾尝试使用TortoiseSVN的重新定位功能，但得到“重新定位只能更改URL的存储库部分”，也许我应该使用Switch，但我担心工作副本的修订

---

svn信息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信息D:\Programy\Eclipse Workspace\LDD\u 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

有答案吗

---

编辑-基于上述输出，我认为您需要采取不同的方法。看起来原始存储库创建为

/data/repository

，存储库中有一个名为

DDL2

的文件夹。这可以通过查看工作副本的“存储库根”值看到

使用

svn开关

，您将无法简单地将存储库的根目录向下推一级。相反，您需要使用

svnmove

围绕新的所需根重新组织回购协议。这意味着您将继续从

/data/repository

提供回购服务，但将

DDL2

下的所有文件移动到顶层

---

当然，如果进行本地编辑，移动一堆文件可能会很痛苦。我会将您的所有更改提交，然后将移动作为一次提交。在执行此操作之前，您需要将

svnserve

args更改回原来的位置。

如果要切换服务器，则需要使用重新定位。例如，如果希望工作副本不再引用svn://192.168.1.35/DDL2/trunk/DD_L2DP 赞成svn://192.168.1.127/DDL2/trunk/DD_L2DP，您将使用重新定位

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's 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's root URL changes (such as a scheme
     or hostname change) but your working copy still reflects the same
     directory within the same repository.

如果要更改工作副本引用的存储库上的目录，请使用此开关。我相信这就是你想要的情况。此操作不影响存储库修订号：它只更新工作副本的URL

---

如果您当前有

svn://192.168.1.35/trunk/DDL2DP

您想创建

svn://192.168.1.35/DD_L2DP/trunk

但它在您的存储库中还不存在。

嗯，我想知道我做错了什么。当我右键单击工作副本并选择OrtoiseSVN->Relocate时，我看到了旧的URL。URL更正后，我选择“确定”并收到一条消息：“看来您正试图将工作副本重新定位到同一存储库中的另一个路径……您真的要重新定位吗？”，是，然后。。。“重新定位只能更改URL的存储库部分”，正如我在第一篇文章中所写。您是否碰巧在

svn://192.168.1.35/

而不是迁移旧版本？另外，在更新之前，旧存储库是在

/DDL2

根目录下还是在URL根目录下，我想我刚刚复制了存储库，但是将svnserve参数更改为：svnserve-d--listen host=192.168.1.35-r/data/repository/ddl2您可以发布

svn info的输出吗svn://192.168.1.35/

和

svn信息。

在您的工作副本中？（将此附加到原始问题可能比添加评论更容易）@RiZe：我根据您的输出更新了我的答案。我认为您需要将

svn服务

args更改回来，只需在工作副本上使用

svn move

。看起来像是

DDL2

是存储库下的文件夹，但不是服务器上包含repo的实际文件夹。这有意义吗？

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's 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's root URL changes (such as a scheme
     or hostname change) but your working copy still reflects the same
     directory within the same repository.