如何将 2 个 Subversion 存储库合并到相同路径
几年前,我们放弃了 PVCS Version Manager 并开始使用 Subversion。当时我们没有将修订历史记录从 Version Manager 导入到 Subversion 中。几年后的今天,我们能够将 Version Manager 修订版导入到 Subversion 存储库中。我不能简单地转储一个存储库并将其加载到另一个存储库中,因为路径是相同的。
是否可以将这两个存储库合并在一起,以便我们可以拥有连续的代码历史记录?
任何帮助将不胜感激。
提前致谢。
院长
A few years ago we moved off of PVCS Version Manager and started using Subversion. At that time we did not import the revision history from Version Manager into Subversion. Now years later we were able to import the Version Manager revisions into a Subversion repository. I cannot simply dump one repository and load it into the other repository as the paths are the same.
Is it possible to merge these two repositories together such that we could have a continuous history of our code?
Any help would be greatly appreciated.
Thanks in advance.
Dean
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
将 PVCS Version Manager 转储到新存储库中,直到您提取原始 Subversion 转储的日期。
然后检查 subversion 中的每个修订(一次一个),概念上是在初始迁移“之后”。按照 subversion 保存的顺序逐一签入每个修订。
Subversion 通过区分文件系统来工作,虽然我认为理论上可以合并到历史记录中,但我无法想象一种“快速”、“简单”或“快速”的方式来这样做(考虑到它的修订编号)方案),无需做大量的“实验”工作。最后,快速模拟(手动完成所有操作)比任何“修补存储库”解决方案更有可能实现。
现在,为了有效地做到这一点,我将编写脚本。我还会仔细研究从原始 subversion 存储库中捕获签入日期和时间,并查看它们是否可以在新的“完整历史记录”存储库中被覆盖。
了解您没有机会保留修订号,并且更改现有存储库的修订号可能比保留历史记录更糟糕。现在有多少“其他”文档引用了错误的修订号?可能想要用描述旧转速号的属性来标记新检查,但即使这样也可能不足以防止混淆。
Dump the PVCS Version Manager into a new repository, up to the date you pulled the original subversion dump.
Then checkout each revision in subversion (one at a time) that conceptually was "after" the initial migration. Check-in each revision, one-by-one, in the same order as was saved by subversion.
Subversion works by differencing file systems, while I imagine it could be theoretically possible to merge in a history, I can't imagine a "fast", "easy", or "quick" way of doing so (taking into account it's revision numbering scheme) without doing a lot of "experimental" work. In the end, a quick simulation (doing everything manually) is a far more likely to work scenario than any "patch the repo" solution.
Now to do this effectively, I would script it. I would also take a close look at capturing check-in dates and times from the original subversion repository and seeing if they can be overridden in the new "complete history" repository.
Understand that you have no chance to preserve revision numbers, and changing the revision numbers of your existing repository might just be worse than keeping the history. How many "other" documents will now refer to the wrong revision number? Might want to tag the new checkings with a property describing the old rev number, but even that might not be enough to prevent confusion.