Re: [Monotone-devel] Re: [cdv-devel] more merging stuff (bit long...)

Nathaniel Smith wrote:
> My approach it is, when you say "merge that thing into my
> tree", you're telling the merge algorithm that you do, in fact, want
> the thing over there to end up in your tree.  

That's the way I work with CVS in eclipse, BECAUSE it has absolutely 
wonderful diff preview capabilities. On a hunk-by-hunk, file-by-file, 
package-by-package, or whole-project basis, I can pull in exactly what I 
want, and nothing else.

On the other hand, this visual diff actually marks conflicts, and the 
puller has the option to not pull conflicts, or to pull conflicts that 
can be automatically resolved. So with that wonderful tool, the logic is 
all nicely integrated.

So far, with most existing distributed SCM tools, there is almost no 
"preview" ability. Especially when pulling tree-to-tree, you generally 
have to pull first, review all the new diffs, and somehow revert out 
what you don't want (which isn't always easy).

If I can't preview the changes before I pull them, then I would prefer 
that the puller err on the side of creating conflicts rather than 
automatically changing my tree and forcing me to go back and manually 
undo what I didn't want in the first place.

> The other thing is that merges aren't really in the position of
> choosing which changes win over another... the tricky part is
> determining what a change _is_ in the first place, and then if once
> you've done _that_ there are two of them in conflict, that's always a
> conflict... but sometimes the first part is hard!

I see what you're saying. But if the merge (conflict identification) 
algorithm can mark potential conflicts with different tags for different 
situations, then the tools that actually do the merging can behave 
differently.

Kevin