monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: OpenEmbedded looking to jump ship


From: Stephen Leake
Subject: Re: [Monotone-devel] Re: OpenEmbedded looking to jump ship
Date: Sun, 04 May 2008 05:35:11 -0400
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (windows-nt)

"Justin Patrin" <address@hidden> writes:

> On Sat, May 3, 2008 at 12:23 PM, Stephen Leake
> <address@hidden> wrote:
>> "Justin Patrin" <address@hidden> writes:
>>
>>  > On Sat, May 3, 2008 at 12:26 AM, Stephen Leake
>>  > <address@hidden> wrote:
>>  >> "Justin Patrin" <address@hidden> writes:
>>  >>
>>  >>
>>  >> > The majority of complaints seem to be that "merge is broken". I
>>  >>  > honestly can't understand this argument. Merge in monotone has always
>>  >>  > been the part that makes the most sense to me. It seems likely that
>>  >>  > the people who say that mtn's merge is broken are not paying
>>  >>  > sufficient attention to what they're doing (such as fragmenting
>>  >>  > history by copying files, then renaming back to the original name).
>>  >>  > Most people seem to be having non-content conflicts, which, I must
>>  >>  > agree, is a part of monotone that is lacking in UI.
>>  >>
>>  >>  I proposed a new process for resolving non-content conflicts; see
>>  >>
>>  >>  http://lists.gnu.org/archive/html/monotone-devel/2008-04/msg00084.html
>>  >>
>>  >>  Would that help?
>>  >
>>  > It looks like that would help
>>
>>  good.
>>
>>
>>  > but I'm sure it would need a UI built into monotone.
>>
>>  Ok. What would that look like?
>
> Just som commands for doing this via the command-line instead of
> manually editing a conflict file. The initial implementation could be
> without the UI but before it lands on mainline I'd think we'd want
> some kind of command-line UI for it.

Ok. Can you suggest some specific commands?

I find editing a conflict file to be simple; I can't think of a set of
commands that would be better.

Remember that there are several different kinds of conflicts; see
monotone/tests/conflict_messages/__driver__.lua for the complete list.

>>  > This is where we'd need suturing.
>>
>>  I don't know how to go about implementing that. Once I get the "drop
>>  one side" solution working, we can work on the better solution.
>>
>
> I just know that suturing is for taking 2 nodes in mtn and making them
> "merge" to the same node somehow. This has been discussed
> previously.

Ok. I've seen some references to that in the test suite. I can search
the mailing list archives for it.

-- 
-- Stephe




reply via email to

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