Mercurial to Mercurial to Subversion 工作流问题 [英] Mercurial to Mercurial to Subversion Workflow Problem

查看:20
本文介绍了Mercurial to Mercurial to Subversion 工作流问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在从 Subversion 迁移到 Mercurial.为了促进迁移,我们正在创建一个中间 Mercurial 存储库,它是我们的 Subversion 存储库的克隆.所有开发人员都将开始切换到 Mercurial 存储库,我们将定期将更改从中间 Mercurial 存储库推送到现有的 Subversion 存储库.一段时间后,我们将简单地淘汰 Subversion 存储库,中间 Mercurial 存储库将成为新的记录系统.

We're migrating from Subversion to Mercurial. To facilitate the migration, we're creating an intermediate Mercurial repository that is a clone of our Subversion repository. All developers will be begin switching over to the Mercurial repository, and we'll periodically push changes from the intermediate Mercurial repository to the existing Subversion repository. After a period of time, we'll simply obsolete the Subversion repository and the intermediate Mercurial repository will become the new system of record.

Dev 1 Local --+--> Mercurial --+--> Subversion
Dev 2 Local --+                +
Dev 3 Local --+                +
Dev 4 -------------------------+

我一直在对此进行测试,但是当我将更改从本地存储库推送到中间 Mercurial 存储库,然后推送到我们的 Subversion 存储库时,我一直遇到问题.

I've been testing this out, but I keep running into a problem when I push changes from my local repository, to the intermediate Mercurial repository, and then up into our Subversion repository.

替代文字 http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/01.png

在我的本地机器上,我有一个已提交并准备好推送到我们的中间 Mercurial 存储库的变更集.在这里您可以看到它是修订版 #2263,哈希值为 625...

On my local machine, I have a changeset that is committed and ready to be pushed to our intermediate Mercurial repository. Here you can see it is revision #2263 with hash 625...

替代文字 http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/02.png

我只将此变更集推送到远程存储库.

I push only this changeset to the remote repository.

替代文字 http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/03.png

到目前为止,一切看起来都很好.变更集已推送.

So far, everything looks good. The changeset has been pushed.

hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

我现在切换到远程存储库,并更新工作目录.

I now switch over to the remote repository, and update the working directory.

hg push
pushing to svn://...
searching for changes
[r3834] bmurphy: database namespace
pulled 1 revisions
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp
adding branch
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
rebase completed

接下来,我将更改推送到 Subversion,效果很好.此时,更改位于 Subversion 存储库中,我将注意力返回到本地客户端.

Next, I push the change up to Subversion, works great. At this point, the change is in the Subversion repository and I return attention back to my local client.

替代文字 http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/04.png

我将更改拉到我的本地机器上.嗯?我现在有两个变更集.我的原始变更集现在显示为本地分支.

I pull changes to my local machine. Huh? I've now got two changesets. My original changeset appears as a local branch now.

替代文字 http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/05.png

另一个变更集有一个新的修订号 2264 和一个新的哈希 10c1...

The other changeset has a new revision number 2264, and a new hash 10c1...

替代文字 http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/06.png

无论如何,我将本地存储库更新为新版本.

Anyway, I update my local repo to the new revision.

替代文字 http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/07.png

我现在换了.

替代文字 http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/08.png

所以,我最后点击了确定并标记传出的变更集",正如您所看到的,Mercurial 仍然想要推出我以前的变更集,即使它们已经被推送了.

So, I finally click the "determine and mark outgoing changesets" and as you can see Mercurial still wants to push out my previous changesets even though they've already been pushed.

显然,我做错了什么.

我也无法合并这两个修订版.如果我在本地机器上合并两个修订版,我最终会得到一个合并"提交.当我将该合并提交推送到中间 Mercurial 存储库时,我无法再将更改推送到我们的 Subversion 存储库.我最终遇到了以下问题:

I also can't merge the two revisions. If I merge the two revisions on my local machine, I end up with a "merge" commit. When I push that merge commit out to the intermediate Mercurial repository, I can no longer push changes out to our Subversion repository. I end up with the following problem:

hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

hg push
pushing to svn://...
searching for changes
abort: Sorry, can't find svn parent of a merge revision.

我必须回滚合并才能回到工作状态.

and I have to rollback the merge to get back to a working state.

我错过了什么?

推荐答案

您没有做错任何事情,事实上,在您的情况下,您看到的行为是预期的(如果对新的 Mercurial 用户有些困惑)结果.

You're not doing anything wrong, in fact in your situation the behavior you're seeing is the expected (if somewhat confusing to a new Mercurial user) result.

hgsubversion 有两方面的好处:

hgsubversion is really good for two things:

  1. 使用 Mercurial 作为 Subversion 的客户端,无需在 svn 之外交换更改
  2. 将 Subversion 存储库转换为 Mercurial

您正试图将其用作更通用的网关,这是一个困难得多的问题.Subversion 对世界的看法非常僵化,我们必须在其中工作.事情的真相是,只有在从 Subversion 中提取修订版本后,才能在使用 hgsubversion 时将修订哈希视为最终版本.因此,如果您的开发人员在没有 Subversion 作为中介的情况下直接在 Mercurial 存储库之间共享变更集,就会发生这种情况.

You're trying to use it as a more generalized gateway, which is a much much harder problem. Subversion has a very rigid view of the world, and we have to work within that. The truth of the matter is that the revision hash can only be viewed as final when using hgsubversion after the revision has been pulled from Subversion. Thus, if your developers ever share changesets between Mercurial repositories directly, without Subversion as an intermediary, this will occur.

rebase 是自动的并且是非可选的,一个非常基本的原因是:Subversion 在您推送时执行该 rebase.如果您在推送时有未拉取的更改,Subversion 会为您执行 rebase,如果成功(使用愚蠢的简单 rebase 算法),它会接受提交,而不会指示发生了 rebase.我们正在拼凑两种不同的模型.

The rebase is automatic and non-optional for a very fundamental reason: Subversion performs that rebase when you push. If you had unpulled changes when you pushed, Subversion did that rebase for you, and if successful (with a stupidly simple rebasing algorithm) it accepts the commit with no indication that a rebase occurred. We're patching together two different models.

我建议立即将所有人转移到 Mercurial - 像这样的混合方法只会在短期内使使用 Mercurial 变得比实际需要的更困难,并可能使不熟悉 DVCS 的用户感到困惑.

I'd recommend moving everyone over to Mercurial at once - a hybrid approach like this is only going to make using Mercurial more difficult in the short term than it needs to be, and potentially confuse users new to DVCS.

这篇关于Mercurial to Mercurial to Subversion 工作流问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆