monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: non-content conflicts AKA Openembedded is dumpi


From: Zack Weinberg
Subject: Re: [Monotone-devel] Re: non-content conflicts AKA Openembedded is dumping monotone because it can merge anything
Date: Thu, 13 Mar 2008 12:16:54 -0400

On Thu, Mar 13, 2008 at 11:51 AM, Koen Kooi
<address@hidden> wrote:
>  Markus Schiltknecht schreef:
>  | Koen Kooi wrote:
>  |> As the subject already hints at, OpenEmbedded is seriously looking at hg
>  |> and git because mtn can't merge any of our branches due to non-content
>  |> conflicts (ncc).

I feel somewhat responsible for having abandoned work on workspace
merge, um, almost two years ago now; that would have addressed most of
your problems.

Dealing with nccs *is* just a simple matter of programming, and for
your case (willing to put up with merge-right-now, only care about
add/add conflict) I think there could be a hackish solution where we
throw those into the content_merge lua hook too.

Are you willing to attempt to code it?  If so, I can commit to
reviewing and/or offering implementation advice.  (I do not have time
to do it myself.  Also I may be offline all of next week.)

>  Would a dialog asking the user which node to drop (or rename) be an
>  acceptible UI?

Honestly, I think it would be okay to do a dumbass heuristic: discard
the conflicting node with the numerically higher node ID.  (which is a
decent approximation to "node with the shortest history").

>  [1] another big problem: mtn has no way of applying the output of 'mtn
>  diff', rendering 'mtn mv' useless

"mtn patch" would be _really easy_ to code.  All you have to do is
strip the leading hashmarks and parse the basic_io header, drop
content-only changes, feed the result to apply_cset(), and then spawn
patch(1) on the remainder of the input.

zw




reply via email to

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