Hi everyone involved in merge-tracking!
The following is a realistic and quite simple sample scenario
which shows that current mergeinfo scheme has a fundamental problem
making it impossible to implement merge tracking correctly
even at some later time. (This is what I mean by dead-end.)
(I am a little confused that nobody seems to care about that problem.
Isn't such a situation a standard case when having multiple branches?
If Subversion fails in such scenarios, won't users complain that
merge-tracking of Subversion is broken? Is it more important to ship
at least something as 1.5?)
r1: Create branch "release" from "trunk"
r2: Create branch "stable" from "trunk"
r3: Create branch "feature" from "trunk"
r4: Commit change "T" to trunk
r5: Commit change "R" to release. R is overlapping with T.
r6: Commit change "S" to stable. S is overlapping with R (but not with T).
r7: Commit change "F" to feature. F is not overlapping with any other change.
Repository:
trunk = T
release = R
stable = S
feature = F
r8: Merge (with merge-tracking) from release into stable.
This gives a conflict, which is manually resolved by change "RSfix".
Repository:
trunk = T.
release = R
stable = R+S+RSfix, mergeinfo=release:1-5
feature = F
r9: Merge (with merge-tracking) from stable into trunk.
This gives a conflict, which is manually resolved by change "RSTfix".
Repository:
trunk = (R+S+RSfix)+T+RSTfix, mergeinfo=stable:1-8,release:1-5(indirect)
release = R
stable = R+S+RSfix, mergeinfo=release:1-5
feature = F
r10: Merge (with merge-tracking) from stable into feature.
No conflicts.
Repository:
trunk = (R+S+RSfix)+T+RSTfix, mergeinfo=stable:1-8,release:1-5(indirect)
release = R
stable = R+S+RSfix, mergeinfo=release:1-5
feature = (R+S+RSfix)+F, mergeinfo=stable:1-9,release:1-5(indirect)
r11: Merge (with merge-tracking) from trunk into feature.
This is the interesting step.
The expected result of r11 is (R+S+RSfix)+T+RSTfix+F.
There should be no conflict, since F is disjunct to any other change.
A correct implementation would for example
first unmerge stable:1-8 (R+S+RSfix), resulting into F,
and then merge trunk:1-10 ((R+S+RSfix)+T+RSTfix), giving the correct result.
It seems that - assuming the Subversion architecture - such kind of
"patch arithmetics" is the only solution at all.
The question is: How does the implementation know to unmerge stable:1-8?
Unmerging both stable:1-8 and release:1-5,
or only unmerging release:1-5 obviously would give a wrong result.
To do the right thing, the merge algorithm must know that the latest
common node in the merge graph of trunk and feature is stable@8,
and that release@5 is only indirect.
But it cannot know this from the current merge info,
because current mergeinfo of trunk and release both contains
stable:1-8 and release:1-5 in the same way.
However, if mergeinfo would contain only the immediate merge history,
then the merge implementation could analyse the merge graph,
and would find out the latest common node in the merge graph
of trunk and feature as being stable@8.
Cheers, Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 30 23:30:25 2007