[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] improving show_conflicts

From: Derek Scherger
Subject: Re: [Monotone-devel] improving show_conflicts
Date: Tue, 19 Feb 2008 23:23:50 -0700
User-agent: Thunderbird (X11/20071116)

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


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]