我们有一个被搞砸的颠覆存储库。想知道是否有一些聪明的方法可以解决它。
根据颠覆日志，基本上这是发生的事情：
- ...古老的历史
- 删除中继
- 创建主干
- 将所有文件重新添加到主干（使用新的更改/移动/添加/删除以获得良好的衡量标准）
- 更多更改/移动/添加/删除
- 更...
这意味着我们已经丢失了第 1 点和第 4 点之间的所有历史记录。这里有什么可以做的吗？还是忽略并继续前进对每个人的理智都是最好的？
问问题
127 次
3 回答
0
可以检索第 1 点和第 2 点中的任何内容。
为此，请按照以下步骤操作。
在存在“主干”的地方，您可以恢复到第 2 点之前的版本。一旦恢复，这应该再次提交到 SVN。
这样一来，之前的所有历史都将被还原，不会有任何损失。
于 2013-05-23T12:17:26.857 回答
0
由于这涉及 URL 的更改，因此您确实不能使用合并。您需要做的是找到旧树干的位置。这并不太难做到。当旧主干被删除时，您会看到 Subversion 修订号。它在svn log. 之前的版本就是你想要的。假设修订版 12345 是旧主干被移除的时间。我们有兴趣恢复修订版 12344。
让我们把新的树干移开：
$ svn mv -m"Getting the 'new trunk' out of the way" $REPO_URL/trunk $REPO_URL/funky_trunk
这样可以使新的行李箱不碍事，但如果您确实需要一些东西，则可以轻松访问。
现在，让我们恢复旧的主干：
$ svn cp -m"Restore the original trunk" -r12344 $REPO_URL/trunk@12344 $REPO_URL/trunk
主干在修订版 12345 中被删除，所以我从修订版 12344 中复制它。这-r12344是文件查看修订版 12344 的方式。这@12344是修订版 12344 的存储库结构。
这将使您的后备箱回到列表中的步骤#1。就好像旧的主干从未被删除。
现在，您需要在步骤 5、6 等中进行更改。您也许可以使用合并工具，但前提是您使用了--ignore-ancestry标志。这是因为虽然旧的主干文件$REPO_URL/trunk/dir/foo.txt和新的主干文件$REPO_URL/trunk/dir/foo.txt在我们肉眼看来是同一个文件，但 Subversion 将它们视为两个不同的文件，因为它们具有完全不同的历史。这就是我们在 ClearCase中称为Evil Twin问题的原因。这也是您对目录进行版本化时所得到的。
真正的问题是为什么要这样做，为什么肇事者没有被枪杀，被扔到一辆快速行驶的公共汽车下，被大象踩踏，然后开枪？
我偷偷怀疑您的网站正在使用原始主干方法。这是主干从未使用过的地方，因为它看起来就像上一个版本一样。这就是标签的用途。
发生这种情况是因为假设有人将最后一个版本放在主干上，如果您有一个非常复杂的分支策略并且没有定期遵循，那么合并到主干可能是一个混乱的过程。例如，您假设分支、合并到主干，然后从主干重新分支，但大多数时候，人们从分支分支。你有一个分支的一个分支几次，你不能将它合并回主干。
那么，那个人是做什么的呢？他们删除主干，然后将分支复制到主干！嘿，最后一个版本是在主干上，我只花了几秒钟，而不是几个小时或合并和比较。
我也因为你对 Subversion 合并的不信任而明白了这一点。如果您合并两个直接相关的分支，Subversion 合并效果很好，并且不要进行混乱的重构。（重构问题可能在 Subversion 1.9 中得到解决，其中 Subversion 将跟踪移动和重命名为实际的移动和重命名，而不是复制和删除）。
如果您尝试合并两个不相关的分支或远距离相关的分支，Subversion 合并会出现问题，并且如果您尝试仅将主干用于最终版本，则会发生这种情况。使用标签来标记您的发布。
在 Subversion 中有几种处理分支的策略。不稳定的主干由大量参与持续集成的站点使用。
敏捷站点更喜欢在自己的分支上创建每个用户故事、缺陷或任务，但是您必须尽早合并这些分支，并且经常返回到某个集成分支。
如果您坚持主干必须只包含发布，请创建一个集成分支并将其用于您的主要工作。从主干分支集成分支，完成后才将集成分支合并到主干。所有其他分支都应该来自集成分支。
于 2013-05-23T22:31:33.917 回答
0
您始终可以从删除之前恢复旧主干，并合并该分支上新主干的更改，然后将其设为 nwe 主干
于 2013-05-23T11:23:51.267 回答