Re: [Monotone-devel] Time for a release

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Stephen Leake schrieb:
>>
>> I'm working on a minimal implementation of conflict resolution; just
>> content and duplicate name conflicts. The duplicate name resolutions
>> will only be rename or drop, not suture.
>>
>> The point of this conflict resolution implementation is to allow
>> preparing conflict resolutions one at a time, before the actual merge
>> command is issued. Then when you do the merge, you can tell it to use
>> the prepared resolutions, so no user interaction is necessary.
>>
>> This avoids the problem of losing work when you encounter a conflict
>> that's complicated and abort a merge.
>
> That sounds pretty cool already. Does this work for workspace merge as
> well, i.e. update?

No, because 'mtn automate show_conflicts' doesn't show workspace
conflicts, so there is no way to generate an appropriate conflicts
resolution file. 

That could be improved in the future, but it will be a lot of work. We
need to add new conflict classes for all the workspace conflicts, and
change the way the core workspace update code to record the conflicts
rather than just reporting them to stderr.

You can always commit and merge before update, so this is not a major
impediment.

>> I'd like this to be in the next release so my team at work can use it,
>> without an internal mtn version.
>
> I'd definitely like to have some people look over the code before it
> gets merged.

Ok. The n.v.m.resolve_conflicts branch is only about half-done, but
the general flavor is right, if people want to start looking at it.

>> So if we can postpone a release until next weekend, I'd appreciate it.
>
> If the others are ok, I guess we can easily release a few days later.
> (After all, we've already waited four months...) My wife and son are
> away from Wednesday, so I guess I'll have more time for different
> things then anways ;)

Ok.

>> On the other hand, the mtn command line interface to this feature is
>> not at all settled. 
>>
>> <snip>
>>
>> Others have expressed a desire for mtn command line operations to add
>> resolutions to the conflict file. I don't plan on using them, and we
>> did not come to any consensus on what they might be, so I'm not
>> implementing them now.
>
> A usable command line would probably be needed, otherwise people which
> don't use Emacs (like me) will find the interface then pretty academic
> and won't use it.

I agree it is needed eventually. I'm not clear it is needed
immediately.

> I'm undecided - even though I wear this nice release manager hat, I
> don't like to say just "yes" or "no" here. I perfectly understand that
> you need it for your team and that people should be encouraged testing
> it and all, but I fear that once the code went into mainline, the
> general (your?) interest making a halfway usable command line which
> does not include editing basic_io files is gone by then...

That's true; holding merging this to mainline until there is a
reasonable command line interface will definitely motivate me to
implement it. And I agree that's a reasonable requirement.

However, I was hoping that someone else would implement that part.

Hmm. I guess it won't be too hard. There is already code that parses
the basic-io conflicts representation and stores it in structures, and
other code that writes out the structures; adding a command that just
read them in, adds one or more resolutions, and writes them back out
would not be hard.

That same command could use the current "need help for merge"
mechanism on content conflicts, one at a time.

It will be difficult to let the user specify which conflict to work
on. Always working on the first unresolved conflict would be
reasonable, I guess. That way you would just provide resolutions in
order; when there are resolutions for all conflicts, you are ready to
merge.

-- 
-- Stephe