我正在维护一个最初没有使用版本控制系统的项目。相反，会有定期保存到备份文件夹中的代码库快照，偶尔会创建一个临时分支。当我抓住项目时，我为它创建了一个Subversion存储库，将每个快照提交到存储库（每次使用WinMerge更新工作副本）并使分支与此备份文件夹中的“昂贵”副本分支对应系统
现在项目已经在Subversion中存在了一段时间，并且开发已经在主干中实时完成，我已经获得了一些从开发人员的机器中提取的旧分支快照文件夹。我发现树干历史上的正确位置是追溯分支...然而，我现在的问题是：如果我创建这个分支，我能用它做些什么吗？我可以追溯性地将此分支合并到trunk的历史记录中，那么分支中的文件是否有额外的文件历史记录？
基本上，我想采用这个旧的“昂贵的副本”分支，从trunk的历史中的适当位置创建一个分支，复制旧分支，将每个旧的备份副本提交到Subversion分支，然后将所有内容合并在适当的位置，如下面粗略的ASCII艺术图所示：
trunk: ... r107 -> r108 -\-> r109 -> r110 -> .... -> r137 -> .... -> r394
old branch: -> r395 -> r396 -> r397 -/ (r398)
当前存储库的修订版是r394。创建分支将是r395。承诺一对“昂贵”的副本将是r396和r397。在r137表示的时间点“之前”合并回主干将使存储库进入r398。现在，从r137开始查看文件的历史记录还包括r396 + r397中提交的更改，然后在r398中合并。
这样的事情可能没有重新提交r137，然后进行合并，然后再次重新提交r394（我认为不会给我想要的东西，无论如何）？
答案 0 :(得分：1)
Subversion允许您从旧快照创建分支，因此您可以从r108分支并将更改（r395-397）提交到该分支。但是，您无法返回并将提交“插入”树的历史记录中。如果您具有对服务器的管理员访问权限，您可以使用svnadmin dump做某种功夫，以便在历史记录中的适当时间将这些更改插入到树中，但它会丢弃所有修订版本在那一点之后的数字（更不用说它将是一个相当复杂的程序）。我无法想象这个过程不会引起各种意外问题，尤其是合并跟踪。
我曾尝试做类似的事情，我发现将历史从非组织系统移植到版本控制系统通常比它的价值更麻烦。相反，我拍了一个代码快照并做了一个干净的休息;使用旧系统在旧服务器上仍然可以使用该快照之前的所有内容，从那时起，所有开发都将在Subversion存储库中完成。我们没有丢失任何信息，所有的历史记录仍然存在，但它要求开发人员访问旧服务器以获取它。起初它很烦人，但几个月之后，Subversion repo已经开发了足够的历史记录，旧系统的构建变得普遍未使用，并被迁移到存档服务器。既然你已经设置了Subversion repo并且包含了历史版本，那么在遗留代码和当前代码之间进行彻底拆分可能为时已晚，但这个想法仍然存在。您可以将此新历史数据添加到托管历史版本的服务器/文件共享中，如果有人想查看超出版本200的文件的最详细历史记录（或者当您停止提交旧版本并开始执行时的任何修订版本号）他们可以检查服务器。