Thomas Moschny <[EMAIL PROTECTED]> writes: > On Monday 01 September 2008 Thomas Keller wrote: >> Stephen Leake schrieb: >> >> > 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. > > Do all tests pass?
Yes, and I'm adding new ones for this 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. >> >> 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. > > While a review could be done in a week, I'm not sure we should really be in a > hurry. We can easily have a 0.42 in a month or so. That would be fine. >> > On the other hand, the mtn command line interface to this feature is >> > not at all settled. >> > >> > <snip> > > Yes, I also think that a cmdline interface for recording resolving decisions > is needed. Not everyone is using emacs. Ok. Is anyone interested in helping to implement that command line interface? > At least the format of MTN/conflicts must be documented properly. That will be done, in the 'automate show_conflicts' section of the monotone manual, and the various resolutions will be in the 'resolve conflicts' section. > Also, test cases are needed. (Maybe this is already done, didn't > find the time yet to have a look at that branch). There will be complete Lua tests for this feature; some are there already. >> > 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? > > Not meaning to discourage you, Stephen, but at this time, and with Thomas > wearing the release manager cap already, I'd say, we'd better have 0.41 done > now, and have your work merged in afterward. Having a 0.42 release within > short time then would be fine and fully justified even by a single new > feature. But of course the decision is up to Thomas as he's doing > the work ;) One issue is who will have time to do the 0.42 release in a month. I could volunteer to be the release manager next time; I'm not sure others would be comfortable with that, since I'm relatively new here. On the other hand, there's no guarantee Thomas Keller will have time in a month, either :). Doing an internal interim monotone release just for my team is a reasonable work-around. Reviewing all the times I've said "that will be done" in this thread, it's looking less likely that it will actually be done this weekend :(. -- -- Stephe _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
