我迁移到新的subversion服务器，但其中一个工作副本仍然指向旧版本。我已经检查了一百多个修订版，我不想丢失我的签到。我将自己回答这个问题，但我认为其他人可能会发现它很有用。
[2014年2月18日新增]
要明确的是，因为我被没有留下任何反馈的人所推崇，而下面的问题似乎不了解情况。
我有三个不同的工作副本指向存储库。我将存储库迁移到新服务器。不幸的是，我将两个工作副本（目录）指向新服务器，并意外地将一个指向旧存储库。我继续检查源代码。当我意识到这个工作副本正在将代码检查到错误的存储库时，对于WRONG存储库有超过100个签入，对新存储库有大约300个签入。合并并不难，除了其中一个文件已被重命名。不知何故，我设法在BOTH存储库中重命名该文件，因此不只是从旧存储库转储100个事务并将它们加载到新存储库中。只有一个重命名事件可能存在。我选择绕过新存储库中的重命名，因为这是我能找到的唯一涉及此目录或文件的事务。我希望这能澄清我造成的混乱，以及为什么清理它很棘手。
答案 0 :(得分：-1)
对于类似的情况有一些很好的指示，但我找不到这个灾难。我以前知道关于颠覆的合理数量，现在我知道了很多。第一个问题，分叉的存储库存在冲突。我重命名了一个文件，弄乱了重命名，并在下一个版本中重新命名。我还在其他存储库中正确地重命名了它，因此我没有机会合并存储库。 Subversion非常清楚。我不得不走原始存储库并找到令人讨厌的修订版（1683,1684）。我使用的是svnx GUI，所以这并不太难。这是必须精确的部分。我不得不将主存储库转储成两部分。这是代码：
svnadmin dump MasterRepository -r 1:1682 > MasterRepository.svn.20140203_1.dump
svnadmin dump MasterRepository -r 1685:1751 --incremental > MasterRepository.svn.20140203_2.dump
请注意，第二个转储是增量转储。也许它可以通过其他方式完成，但这是第一件对我有用的事情。
接下来，只转储自拆分以来其他存储库的修订：
/usr/bin/svnadmin dump OtherDepository -r 1624:1721 --incremental > OtherDepository.dump
现在我需要将原始存储库移开：
cd /Library/Server/Subversion
mv MasterRepository MasterRepository.old
在服务器上创建新存储库：
/usr/bin/svnadmin create MasterRepository
加载三个部分存储库，首先是Master的第一个转储，然后是另外两个：
/usr/bin/svnadmin load MasterRepository < MasterRepository.svn.20140203_1.dump
/usr/bin/svnadmin load MasterRepository < OtherRepository.dump
/usr/bin/svnadmin load MasterRepository < MasterRepository.svn.20140203_2.dump
我仍然遇到svnx不希望允许我将原始目录用作工作副本的问题。我最终把它移到一边。检出新版本，并使用tar复制旧目录并将其粘贴到新目录之上。
tar cvf htdocs.tar htdocs
mv htdocs htdocs.old
（这里我使用svnx检查工作目录，创建目录，创建.svn子目录，并复制存储库分支中的所有文件）
tar xvf htdocs.tar
在svnx中查看，显示为修改过的文件恰好是正确的文件。 可能有一种更优雅的方式来实现这一目标，但我对结果感到满意。