将旧存储库转换为 Mercurial
我一直在尝试不同的版本控制系统,以找到一个我喜欢的版本。我从 SVN 开始(让我们将此版本的项目称为“f1”),然后切换到 GIT。但我不知道如何将旧的 SVN 存储库转换为 GIT,所以我只是复制了该文件夹,删除了 .svn 内容,然后将其转换为 GIT 存储库(让我们将此复制版本称为“f2”)。
现在我正在使用 Mercurial,很高兴地发现它有一个适用于 Windows 的 Tortoise 客户端。我还很高兴地发现将 GIT 存储库转换为 Mercurial 是多么容易,因此我保留了历史记录(我仍然先克隆它,以防万一。所以我将此 hg 版本称为“f3”)。
但现在我想知道的是:我该如何处理仍然保存着我使用 GIT 之前的历史记录的旧 SVN 存储库?
我想我可以将旧的 SVN 存储库转换为 Mercurial,但是我可以将这两个历史记录合并到一个存储库中,以便我在一个地方拥有一组完整的历史记录吗?换句话说,我可以在 f3 前面加上 f1 吗?
I've been playing around with different versioning systems to find one I'm comfortable with. I started with SVN (lets call this version of the project "f1"), then changed over to GIT. But I didn't know how to convert the old SVN repo to GIT, so I just copied the folder, deleted the .svn stuff, and turned it into a GIT repo (lets call this copied version "f2").
Now I'm playing around with Mercurial and was very pleased to find that it has a Tortoise client for Windows. I was also please to find how easy it was to convert the GIT repo into Mercurial, so I preserved the history (I still cloned it first, just in case. So I'm calling this hg version "f3").
But now what I'm wondering is: what do I do with the old SVN repo that still holds my history from before I played with GIT?
I guess I can convert the old SVN repo to Mercurial, but can I then merge those two histories into the one repository so I have a complete set of histories in one place? In other words, can I prepend f1 to f3?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在不从根本上改变 f3 的情况下,您不能在字面历史/祖先意义上将 f1 前置到 f3,因为 Mercurial 中的每个修订都由哈希码标识,并且该哈希码是由(除其他外)构造的修订的内容及其父级的哈希值。因此,更改 f3 第一个节点的父节点将更改 f3 的所有哈希码。
因此,如果您愿意在产生 f4 的过程中重新生成 f3,则可以将 f1 放在 f3 前面。这样做会使 f3 的所有克隆都失效——但如果你是一个人的团队,这可能对你来说没问题。
如果您不同意更改 f3 中的每个哈希(我也不会),另一个(不太好)选择是使用
hg Convert
从 f1 创建一个新的 Mercurial 存储库,让我们调用它是 f5,然后将hg pull -f
f5 转换为 f3。由于 f5 中的变更集不会是 f3 中任何变更集的祖先或子项(没有共同的血统),因此您最终会得到两个头和两个变更集流。有些人这样做,但老实说,我认为这样做没有任何真正的好处。在我这里,我只是将 f1 转换为 f5(一个包含您所有旧历史的 Mercurial 存储库),然后保留它以供参考。
You can't prepend f1 to f3 in the literal history/ancestor sense without fundamentally altering f3, because every revision in mercurial is identified by a hashcode, and that hashcode is constructed from (among other things) the content of the revision and the hashes of its parents. So changing the parent of f3's first node would change all of f3's hashcodes.
So you can prepend f1 to f3 if you're willing to regenerate f3 in the process yielding, say f4. Doing so would invalidate all the clones of f3 out there -- but if you're a one person team that might be okay with you.
If you're not okay with altering every hash in f3 (and I wouldn't be) another (not so great) option is to use
hg convert
to create a new mercurial repo from f1, let's call it f5, and then tohg pull -f
f5 into f3. Since no changeset in f5 would be an ancestor or child of any changeset in f3 -- no common lineage -- you'd end up with two heads and two streams of changesets. Some folks do that, but honestly I don't see any real benefit in doing it.Where I you, I'd just convert f1 into f5 (a mercurial repo with all your old history) and then keep it around for reference.
您是否尝试过移植扩展?它允许您提取更改,即使存储库不相关。
所以你可以做的就是获取 f1,将其转换为你的新存储库,称为 HGSVN。这个存储库将保存您整个 svn 创建的历史记录。如果您没有在 f1 中进行更多修改,则您知道 f3 保存了复制 (f2) 之后的所有修改。现在您可以使用移植,将所有后续更改放入 HGSVN 中。是的,sha1-sums 会被更改,但由于 HGSVN 现在包含您的整个开发历史,您可以忘记其他存储库。
顺便提一句。我建议您在进行实际移植之前进行备份克隆。这样,如果您的命令错误,您可以重新执行一次。希望这有帮助。
Have you tried the Transplant extension? It allows you to pull changes, even if the repository is unrelated.
So what you could do is take f1, do a convert it to your new repo, called HGSVN. This repo will hold you whole svn-created history. If you've done no more modifications in f1, you know that f3 holds all modifications after the copy (f2). Now you can use transplant, to get all the later changes into HGSVN. Yes, the sha1-sums would have been changed, but since HGSVN now contains your entire development history, you can forget about the other repositories.
BTW. I recommend you do a backup clone before doing the actual transplant. This way you can just do it again, if you get the commands wrong. Hope this help.