我迁移到了一个新的颠覆服务器，但其中一个工作副本仍然指向旧的。我已经签入了一百多个修订版，我不想丢失签入。我将自己回答这个问题，但我认为其他人可能会觉得它很有用。
[以下添加于 2014 年 2 月 18 日]
需要明确的是，因为我被没有留下任何反馈的人否决了，下面的问题似乎不理解这种情况。
我有三个不同的工作副本指向一个存储库。我将存储库迁移到新服务器。不幸的是，我将两个工作副本（目录）指向了新服务器，并且不小心留下了一个指向旧存储库。我继续检查源代码。当我意识到这个工作副本将代码签入错误的存储库时，已经有超过 100 次签入到错误存储库，大约 300 次签入到新存储库。合并并不难，只是其中一个文件已被重命名。不知何故，我设法重命名了两个存储库中的文件，所以这不仅仅是从旧存储库中转储 100 个事务并将它们加载到新存储库中的问题。只有一个重命名事件可能存在。我选择绕过新存储库中的重命名，因为这是我能找到的唯一涉及此目录或其中文件的事务。我希望这能澄清我造成的混乱，以及为什么清理起来很棘手。
对于类似情况有一些很好的说明，但我找不到这场灾难的说明。以前我对颠覆的了解相当多，现在我知道的更多。第一个问题，分叉的存储库有冲突。我重命名的一个文件，弄乱了重命名，并在下一个修订版中再次重命名。我还在另一个存储库中正确地重命名了它，所以我不可能只合并存储库。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，显示为已修改的文件正是正确的。可能有一种更优雅的方式来实现这一点，但我对结果很满意。