[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] merge algorithm question
From: |
Markus Schiltknecht |
Subject: |
[Monotone-devel] merge algorithm question |
Date: |
Fri, 09 Dec 2005 11:48:27 +0100 |
Hello,
I'm playing around with monotone rosters and trying to understand the
new merge algorithm. The following test-case made me think:
A
| \
| B
| | \
| | C
D---M1 |
\--+--M2
| |
E |
\ |
M3
M1 is a merge of B and D
M2 is a merge of C and D
M3 is a merge of E and M2
Ancestors of E are:
M1, B, D, A
Ancestors of M2 are:
D, C, B, A
Actual monotone rosters takes A as common ancestor when creating M3,
which renders previous merges useless. I see it would be problematic to
take another ancestor, but couldn't previous merges M1 and M2 be taken
into account somehow? This would reduce a lot of work when merging.
In case your's wondering: I planned to use three branches, one main
branch (revs A and D), multiple branches where I'm developing different
features (this simplified example has only one 'feature'-branch which
consists of revs B, M1 and E) and one combined branch (revs C, M2, M3).
I planned to propagate from the main branch to the features and the
combined branch as well as to propagate from the features branches to
the combined branch.
Of course with only one feature, you could propagate from main to
feature, then from feature to combined. This doesn't work for multiple
features. (Well, it works, but you would have to do the complete merge
work several times :-(
Thank you for your attention.
Regards
Markus
- [Monotone-devel] merge algorithm question,
Markus Schiltknecht <=