[Monotone-devel] Merge behavior w.r.t. file operations

[Ethan Blanton]

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