Stephen Leake schrieb:
Thomas Keller <[EMAIL PROTECTED]> writes:Quite a lot of time (4+ months) passed by since 0.40 was released and a couple of things have been implemented and fixed since then. Though there are no big highlights, I'd still like to do a release just to show that we're still alive. The buildbots (at least those which are working) look reasonable green - the freebsd one has a not enough memory problem, some seem to be offline, but the rest looks ok.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?
Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. I plan to get it done this weekend (Monday included; it's a holidayhere in the US).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.
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 ;)
On the other hand, the mtn command line interface to this feature is not at all settled. I'm implementing this process: mtn automate show_conflicts > _MTN/conflicts add resolutions to MTN/conflicts via Emacs DVC GUI mtn merge --resolve-conflicts-file MTN/conflicts 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.
This minimal command line interface is sufficient to get things started; we can add more commands for the next release, after people have had a chance to experiment. We can also add resolutions for more conflicts. In the meantime, any text editor can be used to add resolutions to the conflict file; it's in basic-io format. However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too.
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...
Other opinions? Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel