[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Merge behavior w.r.t. file operations
From: |
Ethan Blanton |
Subject: |
[Monotone-devel] Merge behavior w.r.t. file operations |
Date: |
Tue, 17 May 2005 20:36:36 -0500 |
User-agent: |
Mutt/1.4.1i |
Hi all,
This is a summary of my viewpoint of how file operations (add, delete,
rename) should work during branch merges, at least partially in reaction
to the long thread "3-way merge considered harmful". I am posting this
summary at the behest of Nathaniel, so hopefully it includes what he
wanted to see (ping me if it doesn't). Note that, while I am supposedly
subscribed to this list, I am yet to receive the first email from it;
please Cc: me in the meantime if there are any responses.
These comments are all predicated on the fact that merges do _not_ hap-
pen without intervention, but are applied to a working copy which must
then be committed by the user. They won't all make sense in the context
of Monotone's current fully automatic merging.
Consider the following merge graph (from the cited thread):
A
|
B
/ \
C D
Let us assume, first, that a file f was added on B->C, but no equivalent
or conflicting file was added on B->D; this is the simplest case. In
this situation, a merge of C and D should create and populate f in the
working directory, with the working metadata updated to reflect this
add.
If f is created in B->C and an identical (content-wise) f' (of the same
name) is created in B->D, the merge of C and D should show no change to
f nee f'.
If f is craeted on B->C and a differing f' is created on B->D, this is
the conflict case for add; the solution here is not clear to me, but I
think it is to issue a warning and either drop a .rej file (I don't know
if this is ever done by monotone) or insert the entire contents of f and
the entire contents of f' with conflict marks.
Consider next a file f which exists in B, and is deleted in C but not D.
In this case, upon merging monotone should mark f as deleted in the
working copy, but leave the file untouched until a commit, at which
point it should be removed if it still exists. This allows a simple
cleans it up upon commit if it is truly to be deleted. The other cases
for delete (both copies delete, neither copy deletes) are uninteresting.
The final case (rename) is somewhat nonuniform with these behaviors, but
I believe what I would expect. If our ill-fated file f is renamed to ff
in C but not in D, then upon merge it should be renamed in the working
copy and the working copy metadata updated to reflect this. For maximum
flexibility, renaming it back to its old self should be simple if so
desired. (Perhaps simply 'mtn mv ff f' is sufficient.)
In the event that f is renamed to ff in C, but renamed to g in D, we
have a trickier problem. Again, like the duplicate conflicting add
case, I would issue a warning and do something not _entirely_ unreason-
able, but I'm not sure just what; simply leaving f in place is undesir-
able, as a status command would then not show any change to its disposi-
tion, but choosing one of the two moves seems difficult.
These decisions are based on what I would call conservatism. Above all
else, I expect my CM system to be conservative. I would additionally
add that 'mtn rm' should behave as in the merged delete behavior above,
and not remove its target until 'mtn ci'. Also, I obviously am a propo-
nent of merges happening in working copy rather than the revision
database, and requiring an explicit commit.
Ethan
--
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
pgprHjdAfMZMv.pgp
Description: PGP signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Monotone-devel] Merge behavior w.r.t. file operations,
Ethan Blanton <=