我重新安装了我的SVN服务器,路径已从svn://192.168.1.35/DDL2/trunk/DD _...更改为svn://192.168.1.35/trunk/DD _...我对工作副本进行了一些更改,并希望在服务器上提交它,因此我需要更改路径/ url ,而不会影响工作副本。
我曾尝试使用TortoiseSVN的重定位功能,但得到“重定位只能更改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
答案 0 :(得分:21)
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
答案 1 :(得分:15)
如果您打算切换服务器,则使用重定位。例如,如果您希望工作副本不再引用svn://192.168.1.35/DDL2/trunk/DD_L2DP而转而使用svn://192.168.1.127/DDL2/trunk/DD_L2DP,则可以使用relocate。 / p>
如果要更改工作副本所引用的存储库中的目录,则使用Switch。我相信这是你想要的。此操作不会影响存储库修订号:它仅更新工作副本的URL。
如果您有svn move
并且想要创建svn://192.168.1.35/trunk/DDL2DP
但您的存储库中尚不存在svn://192.168.1.35/DD_L2DP/trunk
,则会使用{{1}}。
答案 2 :(得分:6)
编辑 - 根据您上面的输出,我认为您需要采取不同的方法。看起来原始存储库创建为/data/repository
,并在存储库中有一个名为DDL2
的文件夹。可以看到您查看工作副本的“存储库根”值。
您将无法使用svn switch
简单地将存储库的根目录推到某个级别。相反,您需要使用svn move
围绕新的所需根重新组织您的回购。这意味着您将继续从/data/repository
投放您的回购,但将DDL2
下的所有文件移至最高级别。
当然,如果您进行本地编辑,移动一堆文件会很麻烦。我将提交所有更改,然后将其作为单个提交进行。在您执行此操作之前,您需要更改svnserve
args。
答案 3 :(得分:1)
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.