monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] considering no merge-into-dir


From: Zack Weinberg
Subject: Re: [Monotone-devel] considering no merge-into-dir
Date: Wed, 08 Oct 2003 20:48:33 -0700
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

graydon hoare <address@hidden> writes:

> Tom Tromey <address@hidden> writes:
>
>> One reason I've wanted merge-into-dir is related to the user
>> experience.  I'd like to be able to configure monotone to use merge3
>> to construct a tree with `<<<<<' (etc) markers, like cvs, that I can
>> then fix up and test at my leisure.  (That way I can use my existing
>> Emacs instance to edit the files, instead of starting a new one each
>> time.)
>
> I strongly support improving the user experience here. I agree, if you
> hit a really big, complex conflict right now the UI is sucks for
> solving it. that needs fixing.
>
> I only meant to point out that there's a good reason not to make such
> "into a tree" behavior the default for all merges.

I'm tired and not thinking clearly, but I would like to make two
observations:

1) A useful thing to do on conflict is to create three files with
   names predictably derived from the base filename: (for example)
   foo.c.GCA, foo.c.LEFT, foo.c.RIGHT.  With the obvious contents.
   It is then possible to apply an intelligent third-party merge
   program such as Ediff (part of Emacs) or the spiffy gui one that
   comes with MacOS X that I can't remember the name of.

2) Regarding the scenario you described earlier, how does this sound?
   If there's no machine-unresolvable conflict, automatically commit
   the merge.  If there *is* a machine-unresolvable conflict, commit
   what would be committed now, but then immediately modify the file
   again, laying down CVS-style conflict markers. and refuse to let
   the user commit it until they've resolved the conflict.

   The graph that would then be produced from your scenario looks
   something like this:


   ... PARENTPIE --- TROMEYPIE  --  AUTOMERGED --- TROMEYFIX
                 \-- GRAYDONPIE --/  (broken)  \-- NJS_doesnt_care_about_pies

  which I believe is the same graph you end up with by leaving stuff
  alone.  This is *effectively* what CVS does if the merge is machine
  resolvable, and if the merge isn't machine resolvable it is enough
  like what CVS does to satisfy principle of least surprise.

  I hope I explained that coherently.

zw




reply via email to

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