A question on ClearCase's merge algorithm
Jorgen Grahn
but hopefully someone has a quick answer, and maybe some insightful
comments. Consider this ASCII ClearCase version tree, and the third
merge (marked with an 'x'):
| bar---/0--/1--/2--/3--------
| | ^ ,---^ x
| | | /
| main--/0--/1-----------------/2
| | | ^
| | ` /
| | \ /
| foo--/0--/1--/2--/3
The merge which created bar/2 rejected most of the changes from branch
foo (maybe because the changes in bar/1 solved the same problem better).
main/2 is identical to foo/3.
When I do the 'x' merge, can I expect to have to make the same
decisions all over again as I did for bar/2?
Because that is what seems to happen in a real-life scenario for me --
I have to deal with the same conflicts again. Since I know main/2 ==
foo/3, I know what to do -- reject all suggested changes -- but it's
still tedious.
In the merge, the base version becomes main/1. Why isn't it foo/3?
I have always thought of the merge arrows as a message from the person
who did the merge to ClearCase:
"I have made sure, best I could, that bar/2 contains all relevant
changes from foo/3. You can now forget about everything which
happened at or before foo/3. I have taken care of it; it's
history now."
But ClearCase doesn't seem to see it that way ...
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
Marc Girod
Sorry, but your graphics make the case ambiguous to me.
I cannot see exactly where you are branching to.
May I recast your case back to text, partly from
your graphics, and partly from your text, which were
to me in contradiction:
/main
/main/0
/main/bar
/main/bar/0
/main/bar/1
/main/bar/2
/main/bar/3
/main/foo
/main/foo/0
/main/foo/1
-> /main/bar/2
/main/foo/2
/main/foo/3
-> /main/2
/main/1
/main/2
-> /main/bar/4 (will be)
Is this correct?
> When I do the 'x' merge, can I expect to have to make the same
> decisions all over again as I did for bar/2?
You take an anthropic view...
The base contributor will be different.
In the first case, the base contributor was /main/0
Now, it will be /main/foo/1.
And yes, the diffs between /main/foo/1 and /main/bar/2
will not be reapplied.
> In the merge, the base version becomes main/1. Why isn't it foo/3?
foo/3 is not an ancestor of bar/3, so it cannot be
a base contributor.
Marc
Brian Cowan
completely separate "subtrees". When the merge starts, only versions on the
tree between the "from", "to" and the "vtree common ancestor" versions will
be considered. So, when merging to \main\bar\4, the only versions you will
look at as possible base versions are:
> /main
> /main/0
> /main/bar
> /main/bar/0
> /main/bar/1
> /main/bar/2
> /main/bar/3
> /main/1
> /main/2
If \main\foo came off of \main\1, the story changes. All of the \main\foo
branch would then be eligible as base candidates since they would all be on
the same subtree.
One note: if you have a very complex vtree where \main\0 is the vtree
common ancestor, you may have some very painful merge performance. I've
seen merges where the tree was 1500+ versions down on both sides that would
take >20 minutes to even get to STARTING a single file merge. You want to
make sure that you are keeping these "subtrees" as small as possible.
Jorgen Grahn
No, not quite correct[1], if I understand your text version.
What I meant was:
- Both foo and bar grow out of /main/1
- foo/3 -> /main/2
- foo/3 -> bar/2
- /main/2 -> bar/4 (will be)
So foo/3 was the source for both my existing merges,
but in your version just foo/1 has been merged to bar.
There is "more" foo/ in main/2 than in bar/3 in your example,
at the time of the final merge.
>> When I do the 'x' merge, can I expect to have to make the same
>> decisions all over again as I did for bar/2?
>
> You take an anthropic view...
> The base contributor will be different.
>
> In the first case, the base contributor was /main/0
> Now, it will be /main/foo/1.
>
> And yes, the diffs between /main/foo/1 and /main/bar/2
> will not be reapplied.
>
>> In the merge, the base version becomes main/1. Why isn't it foo/3?
>
> foo/3 is not an ancestor of bar/3, so it cannot be
> a base contributor.
[I'm following your example now.]
But foo/1 would be an ancestor of bar/3, due to the merge foo/1 ->
bar/2 ? And the final merge would use that information and not bother
me again with the changes in foo/1.
That is what I was hoping for and expecting. In that case, there was
some other reason the third merge was so painful for me in real life.
Maybe I misinterpreted the situation. Hm ...
BR,
Jorgen
[1] I was hoping ASCII art still worked on Usenet, but I suppose too
many interfaces use proportional fonts. I see Google Groups does,
at least by default.
Andrew DeFaria
[1] I was hoping ASCII art still worked on Usenet, but I suppose too many interfaces use proportional fonts. I see Google Groups does, at least by default.
Andrew DeFaria
Why do ballet dancers always dance on their toes? Wouldn't it be easier to just hire taller dancers?
Marc Girod
> Since both \main\foo and \main\bar both split from "\main\0" they are
> completely separate "subtrees".
Right, but only until the first merge between them.
After that, the base contributor will be the source
of the merge.
Anyway, I feel ashamed of not having understood
that the strangeness of the ascii graphics was
due to fixed vs proportional spacing.
Anyway, I prefer text: it is alway more precise,
and offers a clear ordering.
> One note: if you have a very complex vtree where \main\0 is the vtree
> common ancestor, you may have some very painful merge performance. I've
> seen merges where the tree was 1500+ versions down on both sides that would
> take >20 minutes to even get to STARTING a single file merge. You want to
> make sure that you are keeping these "subtrees" as small as possible.
You remind me that I wanted to check the
layout of the source container.
It may well be that physical hierarchy (as
opposed to logical, based on merge arrows)
is advantaged there.
This would be a bug, in fact.
Marc