追溯复制/合并

Question

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

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

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

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

Answer 1

以下是我可以想到的场景以及如何解决它们（如果可能的话）：

1）文件已被复制并且修改已提交（到其原始URL）

1a）如果分支还没有这些文件：

• 将文件（或其封闭目录）复制到分支（这将保留其历史记录）
• 如果中继中没有对这些特定文件进行其他更改，请将这些文件/封闭目录的中继恢复到复制之前的修订
• 如果这些文件的主干发生了变化，您可能仍然可以通过反向合并来获取属于分支的更改：除非某些更改重叠，否则这应该成功

1b）如果分支确实已经有这些文件：

• svn-将trunk的更改合并到分支
• 与1a中相同的主干考虑因素

2）文件已被复制，修改但尚未提交（由于副本没有改变，因此对原始URL进行了修改）

注意：由于修改尚未提交，因此无法保留历史记录，也与主干无关

2a）如果分支还没有这些文件：

• 制作严重复制的文件/目录的物理副本
• 从分支机构的工作副本中删除违规文件夹
• 将以前复制的文件/目录复制/移动到分支机构工作副本中的适当位置
• 将文件添加到分支

2b）如果分支确实已经有这些文件：

• 制作严重复制的文件/目录的物理副本
• 从分支机构的工作副本中删除违规文件夹
• 更新分支的工作副本
• 将以前复制的文件/目录与分支机构现在最新的工作副本中的对应文件合并（*）
• 将文件添加到分支

（*）使用任何常规合并工具进行工作，例如的WinMerge

---

更新：在您编辑之后我更了解您的情况（上面假设在手动复制后，复制的文件夹的URL仍然指向主干）

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

我认为，更好的选择是只更新错误提交到分支的修订版本的日志，以包含复制文件所引用的主干的修订版。这样，如果需要，可以获得信息，但不会有破坏svn未来运营的风险。这种方法的一大缺点是将分支合并回主干可能会有一些必须解决的冲突（因为合并信息没有更新）。执行此操作的命令是svn propset --revprop -r <revision> svn:log <updated log message>

Answer 2

假设复制的文件尚未添加到新位置，我首先考虑的是执行以下操作：

1. 备份当前移动的WC文件
2. 在＃1中执行repo move（保存历史记录）文件;
   • $ svn move -m "Move a file" http://svn.red-bean.com/repos/foo.c http://svn.red-bean.com/repos/blah/foo.c
3. svn up让WC排队
4. 确保文件正确合并，如果不使用＃1中的备份，则文件同步。
5. 提交并继续

Answer 3

我的解决方案不是技术问题。相反，我认为你必须教你的人他们做错了什么，并告诉他们如何正确地做到这一点。什么都不生气。有时人们（包括我自己）做了一些愚蠢的事情，因为他们没有意识到有更好的方法，或者因为他们还没有理解更好的方式。

如果真的经常发生，请注意错误和成功。将结果记录在棋盘上并制作游戏。不要挑选人。一段时间后，问题就会消失。