monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Merging issue


From: Peter Schanhorst
Subject: [Monotone-devel] Merging issue
Date: Mon, 17 Dec 2007 19:09:24 +0100

Hallo all,
Description of my issue follows:

Let start with following sample of revision tree:
o (rev3, branch1)
|
o (rev2, branch1)
|
o (rev1, branch1)

NOTE: descendance: rev1 is parent of rev2 and so on ...

QUESTIONS & REQUESTED functionality:

1) Main scenario: I needed to enforce merge from rev1 to rev3 (or to
rew2) a lot times.
I could not find way how to do it (directly&easily without hacks),
e.g. using the "explicit_merge". Reason&Explanation is mentioned bellow.

2) Manual merge should be specific per merge OPERATION or file type
and NOT per file (as file attribute) and per revision !!!
Current approach - bounding "manual merge" to revision and to file, is
NOT correct from logical and design point of view ...
For example - manual merge should be available via following ways:
a) -----> enforce manual merge per operation: "mtn explicit_merge -r
rev1 -r rev3 --manual-merge=file1 --manual-merge=file2
--manual-merge=file3" or "mtn explicit_merge -r rev1 -r rev3
--manual-merge-all"
b) -----> define manual merge per file type: configure appropriate
merge tools per file type in configuration (e.g. for OpenOffice merger
tool *.doc files, the AltovaXMLSpy tool for *.xml files + merging
operation should shrinked to "copy from source" for pure binary files
like *.dll, *.lib, or for uncofigured files detected as binary (using
some configuration option in config file))
This approach uses Rational ClearCase versioning system, and I think
it is very good.

3) I found, that setting of "mtn:manual_merge" attribute to "true"
value  (for desired files in source and destination revisions) is NOT
enough to enforce manual merge tool for these files.
I expect to execute my custom merge tool during merge operation
(instead of automatic merge algorithm) for these files.
Sample how I'm setting the manual merge attribute:
"mtn attr set file1 mtn:manual_merge true"
"mtn commit"

Current state (of 0.37 version) is, that mtn prepares automatic merge
(using its internal algorithm) for all files with trivial merges and
executes manual merge tool JUST & ONLY for conflicting files - even if
all files have already set mtn:manual_merge attribute to "true" (in
source and destination revisions).

-------------------------------------------------------------------------------------

Explanation why previous point no. 1) is necessary for me:

I know that it could seems strange for somebody, but it is really
useful, especially when you are working in team (more people).
Imagine following situation:
1) rev1: rev1 contains implementation of very good idea, implemented
by experienced teammate, but idea is not fully finished because she/he
leave for vacation
2) rev2: somebody unexperienced totally re-implemented the feature
using different idea (worst idea than in rev1) due to some bugs, and
submitted it to rev2.
3) rev3: somebody else fixed minor bug in rev2 and submitted it in to rev3.

Experienced developer from point 1) came back from vacation and could
not believe he/she is seeing in source code ...
OK, and now, we need to combine some parts of good idea (from rev1)
and merge them !!!MANUALLY!!! in to rev3 - so in general we need to
mix something from rev1 together with something from rev3 and submit
it to rev4 + have clear journal entry (record) in version tree
structure that resulting rev4 comes from merge of rev1 and rev3 revisions.

NOTE: the "mtn explicit_merge rev1 rev3 --branch=branch1" is
DISALLOWED by mtn, and there is not possible to enforce it using some
special cmd parameter.
So we could do it using following ugly "hack":
1) Disprove rev2 and so create new revision rev1.2 (which is the same as rev1)
o-(rev4, branch1, set mtn:manual_merge=true for desired files)
|
o-(rev3, branch1)
|
|                  o-(rev1.3, branch1, set mtn:manual_merge=true for
desired files)
|                  |
|                  o-(rev1.2, branch1)
|                 /
o-(rev2, branch1)
|
o-(rev1, branch1, mtn:manual_merge already set to true for desired  files)
2) set "mtn:manual_merge" attribute to true for desired files in new
revisions - for destination revision "rev4" and for "sure" also in
source revision rev1.3 to "enforce" manual merging desired files ...
3) prepare "explicit_merge rev1.3 rev4 --branch=branch1" - I would
like to express the "rev1.3" in this command
4) Current result: mtn:manual_merge attribute DOESN'T ensure forcing
of manual merge (using preconfigured manual merge tool) for desired
files having files.

This approach is pain in ass ...

I outgrow on Rational ClearCase versioned system and worked with it
many years. It allows to do described scenario without any problems.
And I can say it was used really massive in our project (cca. 500 people).
Of course, I believe it will be also useful form team with more than 1
teammate :)
Clear case also allow prepare somethign like "fake" merge - just to
record in to version tree than revision rev1 was merged to rev3 but
don't make any action - this is useful,
that somebody considered that this merge is useful to have recorded in
revision history just to make revision history more readable in future
when somebody other will analyse the revision history.

Thanks & Regards,
Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]