[英]Mercurial: Merging from unknown divergant 'branch'
I'm trying to do some work on a project called NS-3, but my problem isn't project specific so I thought I'd ask here as well as the relevant mailing list. 我正在尝试在名为NS-3的项目上做一些工作,但是我的问题不是特定于项目的,因此我想在这里询问相关的邮件列表。
Basically, a copy of the then current project code was made, and a fresh repo made of that code. 基本上,制作了当时当前项目代码的副本,并使用该代码制作了新的存储库。 Work was done on both the 'forked' version and the trunk.
“分叉”版本和主干都完成了工作。
So cloned the forked source, cd in, and hg pull <latest-dev>
, hg merge
, and while it wasn't a perfect merge, the changes that were unmergable were all related to one library change, so easily fixed (in theory). 因此克隆了分叉的源,cd in和
hg pull <latest-dev>
, hg merge
,虽然它不是完美的合并,但不可合并的更改都与一个库更改有关,因此很容易修复(理论上)。 Naturally this optimistic attempt failed to build. 自然,这种乐观尝试没有建立。
Now I'm not entirely sure where to go from here, I'm new to DCVS so please; 现在我不确定要从哪里去,我是DCVS的新手,所以请; ideas directed towards a 5 year old!
针对5岁儿童的想法!
How can I find out which changeset of the forked version was last merged against the dev-trunk since they're separate but related repos? 我如何找出分叉版本的哪个变更集最后与dev-trunk合并,因为它们是分开的但又相关的回购协议?
The Case Where You Started With a Copy Not a Clone: 从副本而不是克隆开始的情况:
If this is what happened: 如果发生这种情况:
hg init
is run in each separate copy, creating two unrelated repositories hg init
在每个单独的副本中运行,创建两个不相关的存储库 Then to merge them you want to do this in the newest of the two unrelated repos: 然后要合并它们,您要在两个不相关的存储库中进行最新操作:
hg update 0
, which jumps the repository back to its earliest point -- the point where it last looked identical to the other hg update 0
,它使存储库跳回到最早的点,即它最后一次看起来与另一个相同的点 hg commit
, which creates a new head hg commit
,创建一个新的头部 hg merge
, which merges the two heads and also provides a base revision, which helps the merge process. hg merge
,它合并两个头,并且还提供了一个基本的修订版本,该版本有助于合并过程。 The key is getting a base revision involved if possible. 关键是要尽可能地参与基础修订。 What DVCS systems bring to the table that CVS and SVN don't is that every merge is a 3-way merge between two heads and the most recent common ancestor.
DVCS系统带来的CVS和SVN无法做到的是,每次合并都是两个头和最近的共同祖先之间的三向合并。 Faking that common ancestor by creating the new head off the last point the two repos looked the same (revision 0 in the copy) simulates a base revision.
通过从最后一个点创建新的头部来伪造该共同祖先,这两个存储库看上去相同(副本中的修订版0)可模拟基本修订版。
The Case Where You Started With a Clone Not a Copy 从克隆而不是副本开始的情况
This is the classic DVCS case and there shouldn't be much you need to do. 这是经典的DVCS案例,不需要做太多事情。 Just go into one of the clones,
hg pull
from the other and fire off the hg merge
. 只需进入其中一个克隆,将
hg pull
从另一个克隆中hg pull
,然后触发hg merge
。 If the merge requires input you'll use hg resolve
to provide it, and when you're done hg commit
. 如果合并需要输入,则将使用
hg resolve
提供它,并在完成后使用hg commit
。
If at this point your code isn't building/running then you need to just start debugging. 如果此时您的代码尚未构建/运行,则只需开始调试。 Use
hg blame
to see what was being done near the lines that won't compile and try to suss out what was being done and how to work on it. 使用
hg blame
来查看正在编译的代码行附近正在做的事情,并尝试怀疑正在做的事情以及如何进行处理。
The merge process is much easier the more frequently you do it. 合并过程是很容易越频繁,你做到这一点。 Pull in up-stream changes daily, not monthly.
每天(而不是每月)进行上游更改。
You can turn on the GraphLog extension and use the hg log -G
command to see the point at which the two lines of development diverged, but in the end merging is development, and you just need to approach a non-building merge like you would any other software defect. 您可以打开GraphLog扩展,并使用
hg log -G
命令查看两行开发的分歧点,但最终合并是开发,您只需要像对待非建筑合并那样进行任何其他软件缺陷。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.