SVN重新定位还是切换?

时间:2009-11-29 20:14:07

标签: svn

我重新安装了我的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

4 个答案:

答案 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.