从Mercurial到Mercurial到Subversion的工作流程问题 [英] Mercurial to Mercurial to Subversion Workflow Problem
问题描述
我们正在从Subversion迁移到Mercurial.为了促进迁移，我们正在创建一个中间的Mercurial存储库，该存储库是Subversion存储库的副本.所有开发人员都将开始切换到Mercurial存储库，我们将定期将更改从中间Mercurial存储库推送到现有的Subversion存储库.一段时间之后，我们将简单地淘汰Subversion存储库，而中间的Mercurial存储库将成为新的记录系统.
Dev 1 Local --+--> Mercurial --+--> Subversion
Dev 2 Local --+ +
Dev 3 Local --+ +
Dev 4 -------------------------+
我已经对此进行了测试，但是当我将更改从本地存储库推送到中间的Mercurial存储库，然后再推送到我们的Subversion存储库时，我一直遇到问题.
替代文本http://bmurphy.mediafly.com.s3.amazonaws.com /images/mercurial/01.png
在我的本地计算机上，我有一个变更集，该变更集已提交并准备将其推送到我们的中间Mercurial存储库.在这里，您可以看到它是带有哈希625的修订版#2263.
替代文本http://bmurphy.mediafly.com.s3.amazonaws.com /images/mercurial/02.png
我只将此更改集推送到远程存储库.
替代文本http://bmurphy.mediafly.com.s3.amazonaws.com /images/mercurial/03.png
到目前为止，一切看起来都不错.变更集已推送.
hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
我现在切换到远程存储库，并更新工作目录.
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存储库中，我将注意力返回到本地客户端.
替代文本http://bmurphy.mediafly.com.s3.amazonaws.com /images/mercurial/04.png
我将更改拉到本地计算机. ??我现在有两个变更集.我原来的变更集现在显示为本地分支.
替代文本http://bmurphy.mediafly.com.s3.amazonaws.com /images/mercurial/05.png
另一个变更集具有新的修订号2264和新的哈希10c1 ...
替代文本http://bmurphy.mediafly.com.s3.amazonaws.com /images/mercurial/06.png
无论如何，我将本地存储库更新为新版本.
替代文本http://bmurphy.mediafly.com.s3.amazonaws.com /images/mercurial/07.png
我现在切换了.
替代文本http://bmurphy.mediafly.com.s3.amazonaws.com /images/mercurial/08.png
因此，我最终单击确定并标记传出的变更集"，如您所见，Mercurial仍然希望推出我以前的变更集，即使它们已经被推送了.
很显然，我做错了什么.
我也无法合并两个修订版.如果将两个修订合并到本地计算机上，则会导致合并"提交.当我将合并提交推送到中间的Mercurial存储库时，我不能再将更改推送到我们的Subversion存储库.我最终遇到以下问题:
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.
而且我必须回滚合并才能恢复到工作状态.
我想念什么?
您没有做错任何事情，实际上在您所遇到的情况下，您所看到的行为是预期的(如果使新的Mercurial用户感到困惑)
hgsubversion确实对两件事有好处:
- 使用Mercurial作为Subversion的客户端，而无需在svn之外交换更改
- 将Subversion存储库转换为Mercurial
您正试图将其用作更通用的网关，这是一个非常困难的问题.颠覆对世界有非常死板的看法，我们必须在其中进行工作.事情的真相是，只有在从Subversion提取修订后使用hgsubversion时，修订哈希才可以视为最终版本.因此，如果您的开发人员曾经在Mercurial存储库之间直接共享变更集，而没有使用Subversion作为中介，则会发生这种情况.
重新设置是自动的，并且是非可选的，这是非常基本的原因:在您推送时，Subversion执行该重新设置.如果您在推送时进行了未拉出的更改，则Subversion会为您进行重新设置基准，并且如果成功(使用愚蠢的简单重新设定基准算法)，则它接受提交而没有任何迹象表明发生了重新基准.我们正在将两个不同的模型修补在一起.
我建议立即将所有人转移到Mercurial-这样的混合方法只会在短期内使Mercurial的使用比实际需要更加困难，并可能使刚接触DVCS的用户感到困惑.
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 -------------------------+
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.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/01.png
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...
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/02.png
I push only this changeset to the remote repository.
alt text 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
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.
alt text 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.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/05.png
The other changeset has a new revision number 2264, and a new hash 10c1...
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/06.png
Anyway, I update my local repo to the new revision.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/07.png
I'm now switched over.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/08.png
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.
Clearly, I'm doing something wrong.
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.
What am I missing?
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 is really good for two things:
- using Mercurial as a client for Subversion, without exchanging changes outside of svn
- Converting Subversion repositories to 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.
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.
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到Mercurial到Subversion的工作流程问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
