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

[graydon hoare]

Tom Tromey <address@hidden> writes:

> graydon> I don't know why this is a different issue than just 2
> graydon> heads. can you elaborate?
> 
> If I can selectively merge, then work can be usefully parallelized.

oh, yeah. totally. I thought you meant there was some technically
different issue about how to resolve conflicts into a directory when
there's > 2 merge candidates.

certainly the UI needs the option to "just merge some of the heads".

> For instance, I can take responsibility for always merging a new head
> I "create" (neglecting the fact that the result of a merge is another
> new head, which I might not be so confident about merging).  This has
> the nice property that I only need to be an expert in my part of the
> project, not in everything.

well, simply masking off the merges you don't feel like doing should,
I think, accomplish what you want. consider that this is only an issue
when there are *conflicts*, and when those conflicts are something you
literally "don't know anything about", or can't resolve yourself.

this situation implies that somewhere, someone *does* know or care
enough about the conflict to resolve it. so for you, the "don't care"
person, all you have to do is sit back and wait. and have some way of
telling monotone to wait, not even try the merge. update will still
work (it only re-parents down your existing fork) and merges which
ignore that unresolved conflict will still work. you just need to wait
for someone to resolve it.

this ultimately brings *more* concurrency to the task. the ability to
restrict merging to a subset of a branch is essentially the ability to
create temporary "micro-branches" on the fly, as needs require.

in fact, monotone could be taught to behave this way automatically:
make "merge" try all possible pairwise merges of the heads, and commit
whichever grouping produces the fewest new conflicting heads (== 1, if
everything goes smoothly). then have a separate "resolve" command
which does manual-intervention stuff, for conflicting heads. this way
branches would naturally bifurcate in the presence of "big changes",
and people's work would merge with whichever edge of a "big change"
fork it "merged best" with. it would even make sense, then, to make
"update" always do one of these "merge" operations (only merge
non-conflicting heads) before doing the update, to try to fold as many
changes into your working copy as possible.

might be expensive to calculate on a big project, and might produce
weird results.. what do you think?

> This is one nice feature of the cvs/svn forced serialization model
> -- the person doing the merge is usually already an expert for the
> conflicted code.

yeah, but it also means that 1 person can "win" the race to commit,
and in so doing force N people to do conflict resolution in their
working copies, if the winner's change was really invasive.

> Perhaps I'm worrying too much about edge cases.  My concern is to
> lower the cost of doing a merge, so that anti-social activity is
> less attractive.

no, it's good to talk about. keep bouncing the ideas around :)

-graydon