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

[Tom Tromey]

graydon> (actually, a simple enough UI for this is to let "merge" take a
graydon>  directory full of "hints" -- merged files -- as an optional argument,
graydon>  and dump such a directory full of conflicts when it cannot
graydon>  auto-merge. good enough?)

Yeah, I think so.  This is basically merge-into-dir-with-a-twist.

The files in this case could be the result of running the lua merge
hook.  Somebody who prefers the default hooks would end up with a
merged directory; I could get a directory of merge3 outputs.

>> Finally, one other issue here is what to do when there are more than
>> two heads.

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.
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.

If "monotone merge" always means "merge all heads", then it is
conceivable that for a very large project, no one is capable of
performing the merge.  For instance, I could picture this happening
with gcc (a low probability event, naturally).

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.

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.

Tom