svn - 追溯复制/合并

Question

有时用户会使用 Windows 资源管理器复制文件并在他们应该执行 svn 存储库级别的复制或合并时提交它们。因此，SVN 没有正确跟踪这些变化。一旦我发现这一点，损坏显然已经完成，并且可能已经对相关文件进行了很多后续编辑。重要的是不要丢失这部分历史。当我发现这些情况发生时，我可以做些什么来追溯改进存储库中的内容？

具体来说，我有两种情况，具体取决于目标文件是否已经存在。在第一个场景中，(1) 用户执行了未记录为副本的添加。在第二种情况下，(2) 用户执行了未记录为合并的更新。

此外，源文件和目标文件都经历了也已提交的后续更新。有时，这些后续编辑也是手动对双方进行的，因此没有正确的合并信息。

可能性:可以手动将mergeinfo revprop 添加到过去的修订帮助中吗？如果是这样，我该怎么做？请考虑这两种情况。

Answer 1

以下是我能想到的场景以及如何解决它们(如果可能的话):

1) 文件已被复制并已提交修改(到其原始 URL)

1a) 如果分支还没有这些文件:

svn-copy 文件(或它们的封闭目录)到分支(这将保留它们的历史)

如果主干中的那些特定文件没有其他更改，则将这些文件/封闭目录的主干恢复为副本之前的修订版

如果这些文件的主干发生了更改，您仍然可以通过反向合并来获取属于分支的更改:这应该会成功，除非某些更改重叠

1b)如果分支确实已经有这些文件:

svn-merge 主干对分支的更改

中继线的注意事项与 1a)

2)文件已被复制，已进行修改但尚未提交(到其原始 URL，因为副本没有更改)

注意:由于尚未提交修改，因此没有要保存的历史记录，也与主干无关

2a) 如果分支还没有这些文件:

制作复制错误的文件/目录的物理副本

从分支的工作副本中删除有问题的文件夹

将先前复制的文件/目录复制/移动到分支工作副本中的适当位置

将文件添加到分支

2b)如果分支确实已经有这些文件:

制作复制错误的文件/目录的物理副本

从分支的工作副本中删除有问题的文件夹

更新分支的工作副本

合并(*)之前复制的文件/目录与分支现在最新的工作副本中的对应文件/目录

将文件添加到分支

(*) 使用任何常规的合并工具来完成这项工作，例如WinMerge

更新:在您编辑后，我更了解您的情况(以上假设在手动复制后，复制文件夹的 URL 仍指向主干)

您可以尝试使用 svn propset --revprop -r <revision> snv:mergeinfo <updated mergeinfo> (除非被 pre-revprop-change 钩子(Hook)阻止)在分支上“修复”合并信息，但我相信您也必须“修复”所有后续修订版的合并信息，因为 svn 将这些信息用于其操作(例如合并)；此外，由于后者，您必须非常小心更新的内容。

我认为，一个更好的选择是只更新不正确提交到分支的修订版的日志，以包括复制文件所引用的主干的修订版。这样，如果需要，信息是可用的，但不会有扰乱 svn future 操作的风险。这种方法的最大缺点是，将分支合并回主干可能会产生一些必须解决的冲突(因为未更新合并信息)。执行此选项的命令是 svn propset --revprop -r <revision> svn:log <updated log message>