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

[Zack Weinberg]

More random and not very coherent thoughts:

* A rename conflict could be reconceptualized as a text conflict of
  the manifest file.

  I don't know how painful it would be for the user to deal with this,
  but I do know that when I tried to write down a complete ontology of
  conflicting tree structure changes it listed about 15 different
  cases and I couldn't satisfy myself I'd thought of them all.  And I
  know that PRCS handles rename conflicts by turning them into text
  conflicts in its (rather different) manifest file, and that seems to
  work okay.

* Microbranches are really cool.  But, in my head, their primary
  utility is, if you don't want to deal with a merge conflict, you can
  rewind to a known good version and work from there.

* Big merges are insanely painful in CVS.  Some observations from
  this:

  - CVS conflict markers are not very helpful and I would not miss
    them if they went away.  Something feedable to Ediff is much
    better.  However, to ease transition, I think a mode in which
    similar conflict markers are generated would be useful.

  - CVS conflict detection is too conservative.  It is often the case
    that revisions A and B with ancestor S conflict, but applying the
    diffs S->A, S->B in succession succeeds with no complaints.

  - It is very useful to be able to rewind THE ENTIRE TREE to a
    known-good state.  In fact, I want an 'update' mode in which if
    any file version causes a conflict, the entire tree version
    containing that file version is backed out.

  - I want pluggable conflict detection and resolution, so that
    someone can innovate a merge tool that understands the syntax
    of each programming language.

* I'm not sure how useful partial merges would be.  I do take a huge
  change sometimes and split it into chunks - but on logical
  boundaries, not file boundaries, and I don't know how to automate
  logical boundaries.

  Maybe: given a version graph like so


    BASE --- MEL.1  --- MEL.2  --- MEL.3
         \-- DAVE.1 --- DAVE.2 --- DAVE.3

  where it is now desired to merge the heads, try applying DAVE.1,
  .2, .3 in succession to the MEL branch.  Or the other way round.
  Or each .1 and then each .2 and so on.  This is something where
  a spiffykeen user controllable merge tool would be nice.

zw