SVN重新定位还是切换？

Posted 2021-04-05

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

Path: D:ProgramyEclipse WorkspaceLDD_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.