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. This is the biggest impediment to using mtn for my team at work; they are scared of merging, because of the uncertainty involved in the conflict resolution process. This is especially true for propagating between branches; there are typically many small conflicts that must be reviewed. All of the code I need is in n.v.m.automate_show_conflicts, which also implements suture (but not fully yet). I'm subsetting that into n.v.m.resolve_conflicts (yes, the branch names are not the best). 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 holiday here 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. So if we can postpone a release until next weekend, I'd appreciate it. 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. 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. -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel