|
From: | Derek Scherger |
Subject: | Re: [Monotone-devel] improving show_conflicts |
Date: | Tue, 19 Feb 2008 23:23:50 -0700 |
User-agent: | Thunderbird 2.0.0.9 (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 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
[Prev in Thread] | Current Thread | [Next in Thread] |