2

我对为什么子目录合并不好做了一些研究，最近在我们的存储库中发现了一个子目录，上面有 mergeinfo。

我正在尝试手动删除此合并信息，并想看看我是否正确理解 mergeinfo 并正确执行。

ROOTDIR 合并信息

/分支/迭代53：18065-18126

/分支/迭代54：18150-18204,18210-18231

/branches/Iteration55:18341,18348,18353-18355,18357,18364-18365 <===== 这行不同

/分支/gds返工：17329-17457

/主干：17869,18085

SUBDIR 合并信息

/分支机构/Iteration53/kiwi-web:18065-18126

/branchs/Iteration54/kiwi-web:18150-18204,18210-18231

/branches/Iteration55/kiwi-web:18336-18428 <===== 这行不同

/branchs/gdsRework/kiwi-web:17329-17457

/trunk/kiwi-web:17869,18085

两者之间只有 1 行不同。我还注意到 SUBDIR 合并信息中的 18336-18428 范围包括 ROOTDIR 合并信息中同一行的所有修订。

所以我的计划是用 SUBDIR 中的行替换 ROOTDIR 中的那一行，然后一起删除 SUBDIR 合并信息：

新的 ROOTDIR 合并信息

/分支/迭代53：18065-18126

/分支/迭代54：18150-18204,18210-18231

/branches/Iteration55:18336-18428 <===== 现在与 SUBDIR 合并信息相同

/分支/gds返工：17329-17457

/主干：17869,18085

SUBDIR 合并信息被删除。

这安全吗？陷阱会在哪里？先感谢您。

4

1 回答 1

3

不建议手动编辑mergeinfo。尽管过去我做了您所描述的事情，即使根目录和子目录之间的差异更加复杂，但这种编辑非常容易出错，因此需要格外小心和准确。正如我后来了解到的，SVN 足够强大，可以很容易地解决这种情况；所以最好不要养成手动合并信息编辑的习惯。

简单的情况是 SUBDIR 合并信息中记录的“额外”修订仅影响该子目录。在这种情况下，您只需要在 ROOTDIR 级别对修订 18336 到 18428 进行仅记录合并。仅记录合并将在不触及任何文件的情况下更新 ROOTDIR 的合并信息，并且由于 SUBDIR 合并信息将与 ROOTDIR 完全相同，因此它将删除过多。

  • 如果您直接使用 SVN 命令，只需将--record-only选项添加到svn merge您将用于真正合并的命令中。
  • 如果您使用 GUI 客户端，请在其合并对话框中查找“仅记录”或类似名称的选项。

请注意 mergeinfo 中的范围（包括其两端和其间的所有内容）和-r选项中的范围（指定两个版本以获取差异）之间的区别；例如，在命令行中您需要指定-r 18335:18428，即获取差异的起始版本比要合并的第一个版本小一个。

更复杂的情况是，如果这些修订合并到 SUBDIR 而不是 ROOTDIR 也会更改 SUBDIR 之外的文件。这些更改很可能尚未合并。如果忽略这些更改是安全的，那么您也可以进行仅记录合并。相反，如果碰巧错过了这些更改，您可能希望对 ROOTDIR 级别的修订进行定期合并，并修复合并冲突（如果有）。

合并（仅记录或常规）完成后，检查目录的合并信息是否正确更改，并提交结果。

一篇很好的文章在这里我学到了很多关于 mergeinfo 以及它是如何被 SVN 命令操作的（包括仅记录合并、mergeinfo elision 等），在这里：Subversion 1.5 Mergeinfo - Understanding the Internals。我建议您在尝试修复存​​储库中的 mergeinfo 之前阅读该内容。

于 2012-11-02T22:34:41.213 回答