颠覆：追溯合并？
我正在维护一个最初未使用版本控制系统的项目。相反，会将代码库的定期快照保存到备份文件夹中，并且偶尔会创建一个临时分支。当我掌握该项目时，我为它创建了一个 Subversion 存储库，将每个快照提交到存储库（每次使用 WinMerge 更新工作副本）并创建分支以与此备份文件夹中的“昂贵”副本分支相对应系统。
现在该项目已经在 Subversion 中运行了一段时间，并且开发已经在主干中实时完成，我已经获得了一些从开发人员计算机中提取的旧分支快照文件夹。我在主干的历史记录中找到了正确的位置来追溯分支...但是，我现在的问题是：如果我创建这个分支，我可以用它做任何有用的事情吗？我可以追溯性地将这个分支合并到主干的历史记录中，以便分支中的文件有额外的文件历史记录吗？
本质上，我想采用这个旧的“昂贵的副本”分支，从主干历史记录中的适当位置创建一个分支，复制旧分支，将每个旧备份副本提交到 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 的情况下进行类似的操作（无论如何，我认为这不会给我想要的东西）？
I'm maintaining a project that was not initially using a version control system. Instead, there would be periodic snapshots of the code base saved into a backup folder, and there would occasionally be a makeshift branch created. When I got a hold of the project, I created a Subversion repository for it, committed each snapshot to the repository (using WinMerge to update the working copy each time) and made branches to correspond with the "expensive" copy branches in this backup folder system.
Now that the project has been in Subversion for a while, and development has been done in real time in the trunk, I've been given a few older branch snapshot folders that were pulled from a developer's machine. I found the right spot in the trunk's history to retroactively branch from... however, my question now is this: If I create this branch, is there anything useful I can do with it? Can I retroactively merge this branch into trunk's history, so there's extra file history available for a file from the branch?
Essentially, I would like to take this old "expensive copy" branch, create a branch from the appropriate spot in trunk's history, copy the old branch over, commit each old backup copy to the Subversion branch, and then merge everything back in at the appropriate spot, as can be seen in the following crude ASCII-art diagram:
trunk: ... r107 -> r108 -\-> r109 -> r110 -> .... -> r137 -> .... -> r394
old branch: -> r395 -> r396 -> r397 -/ (r398)
The current repository's revision is r394. Creating the branch would be r395. Committing a couple "expensive" copies would be r396 and r397. Merging back into trunk "before" the point in time represented by r137 would bring the repository to r398. Now, viewing the history of a file anywhere from r137 on would also include the changes committed in r396 + r397 and subsequently merged in r398.
Is something like this possible without re-committing r137, then doing the merge, then re-committing r394 again (which I don't think would give me what I want, anyway)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Subversion 允许您从旧快照创建分支，因此您可以从 r108 分支并将更改 (r395-397) 提交到该分支中。但是，您无法返回并将提交“插入”到树的历史记录中。如果您具有服务器的管理员访问权限，您可能可以使用 svnadmin dump 进行某种功夫，以在历史记录中的适当时间将这些更改插入到树中，但它会失败该点之后的所有修订号（更不用说这将是一个相当复杂的过程）。我无法想象这个过程不会导致各种意想不到的问题，尤其是合并跟踪。
不久前我尝试做类似的事情，我发现将历史记录从无组织的系统移植到版本控制系统通常比它的价值更麻烦。相反，我拍摄了代码快照并进行了彻底的突破；该快照之前的所有内容仍然可以在使用旧系统的旧服务器上使用，从那时起，所有开发都将在 Subversion 存储库中完成。我们没有丢失任何信息，所有历史记录仍然存在，但需要开发人员访问旧服务器才能访问它。一开始这很烦人，但几个月后，Subversion 存储库已经发展了足够的历史，旧系统的构建通常不再使用，并被迁移到存档服务器。由于您已经设置了 Subversion 存储库并包含了历史版本，因此在遗留代码和当前代码之间进行清晰的划分可能为时已晚，但这个想法仍然成立。您可以将此新的历史数据添加到托管您的历史构建的服务器/文件共享中，并且如果有人想查看修订版 200 之外的文件的最详细历史记录（或者当您停止提交旧构建并开始执行时的任何修订号）积极开发），他们可以检查服务器。
Subversion allows you to create a branch from an old snapshot, so you can branch off from r108 and commit your changes (r395-397) into that branch. However, you can't go back in and "insert" a commit into the tree's history. If you have administrator access to the server, you may be able to do some kind of kung fu with
svnadmin dumpto insert these changes into the tree at the appropriate time in the history, but it would throw off all of your revision numbers following that point (not to mention it would be a rather complicated procedure to go through). I can't imagine that process not causing all sorts of unexpected problems, especially with merge tracking.I tried to do something similar a while back, and I found that porting history from a non-organized system into a version control system was usually more trouble than it was worth. Instead, I took a code snapshot and made a clean break; everything before that snapshot was still available on the old server using the old system, and from that point onward all development would be done in the Subversion repository. We didn't lose any information and all of the history was still there, but it required developers to access the old server to get to it. It was annoying at first, but after a couple of months, the Subversion repo had developed enough of a history of its own that the builds from the old system became generally unused and were migrated out to an archive server. Since you've already set up your Subversion repo and included historical builds it's probably too late to make a clean split between legacy code and current code, but the idea still holds. You can add this new historical data to a server/fileshare that is hosting your historical builds and if anyone wants to see the most detailed history of a file beyond revision 200 (or whatever the rev number was when you stopped committing old builds and started doing active development), they can check the server.