我重新安装了我的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
编辑 - 基于您上面的输出，我认为您需要采取不同的方法。看起来原始存储库是作为/data/repository创建的，在存储库中有一个名为DDL2的文件夹。可以看到您查看工作副本的“存储库根”值。
您将无法使用svn switch简单地将存储库的根目录推到一个级别。相反，您需要使用svn move来重新组织新的所需根目录。这意味着你将继续从/data/repository服务你的repo，但是将DDL2下的所有文件移到顶层。
当然，如果你有本地编辑，移动一堆文件可能会很痛苦。我将提交所有更改，然后将其作为单个提交进行。在你做到这一点之前，你需要更换你的svnserve args。
This question有答案。 Specifically：
svn switch --relocate http://svn.example.com/path/to/repository/path/within/repository http://svnnew.example.com/new/repository/path/within/repository
如果您打算切换服务器，则使用重定位。例如，如果您希望工作副本不再引用svn：//192.168.1.35/DDL2/trunk/DD_L2DP而转而使用svn：//192.168.1.127/DDL2/trunk/DD_L2DP，则可以使用relocate。
如果要更改工作副本引用的存储库上的目录，则使用Switch。我相信这是你想要的。此操作不会影响存储库修订号：它仅更新工作副本的URL。
如果您目前拥有svn move并且想要创建svn://192.168.1.35/trunk/DDL2DP但是它在您的存储库中尚不存在，则使用svn://192.168.1.35/DD_L2DP/trunk。
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.