Re: [Monotone-devel] improving show_conflicts

[Derek Scherger]

Stephen Leake wrote:
> Markus Schiltknecht <address@hidden> writes:
>
> > Stephen Leake wrote:
> >
> > > By "automate merge" I meant that mtn would "prompt" the GUI for help
> > > when it got to a conflict. But I don't think the automate stdio
> > > interface supports interaction like that, so I guess I really mean we
> > > need a way to do all the steps that "merge" currently does via
> > > automate stdio. That capability may already be there; I'm not sure.
> > > The first step would be "give me a list of all non-content
> > > conflicts".
> > > I don't see that in the automate commands yet. Adding that might
> > > actually be easier than adding --drop-merge-right to merge; I'll look
> > > into it.
> > I'd prefer such an approach a lot. And yes, the automate interface
> > could certainly do more in that area. A "try this merge" command
> > (which would return possible non-content conflicts as well as content
> > conflicts) would be very nice, IMO.
>
> It turns out there is such a command already; show_conflicts.
>
> However, I'd like it to default to the two current heads as merge does. 

I thought the other day that it would be nice if show_conflicts could 
also take one or two --revision options and work something like diff. 
i.e. show_conflicts -r xxx would show the conflicts if you were to 
update the current workspace to the specified rev. show_conflicts -r xxx 
-r yyy would show the conflicts between the two specified revisions. At 
the time I was thinking that without any -r options it would show the 
conflicts between the current workspace and the revision that update 
would choose as its target. This kinda collides with defaulting to the 
two current heads, but I'm not so sure that makes sense anyway, as there 
might be 3 or more current heads, or one, etc. I suppose it could take 
the first two heads that merge would work with first.

> And I'd like an automate basic_io version of it, for use by Emacs DVC. 
>
> I'll work on this.

Great!

Note that show_conflicts will list content conflicts for any files that 
have changed on both sides, regardless of whether they would merge 
cleanly or not. It's only looking at the content hash.

I was also looking at being able to run a default content merge to see 
if there really is a conflict, but that will require a slight change to 
the content_merge_adaptor classes so that this test merge doesn't 
accidentally go and save some changes to the database. There are a 
couple of approaches to handle this, either change the current adaptors 
so they have a flag controlling whether they will record merges or not, 
or create a wrapper for the adapters that makes the record function a no-op.

Cheers,
Derek