[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] 0.26 status update
From: |
Nathaniel Smith |
Subject: |
[Monotone-devel] 0.26 status update |
Date: |
Tue, 4 Apr 2006 04:07:13 -0700 |
User-agent: |
Mutt/1.5.11 |
I merged the last of the exhaustive merging tests to mainline tonight.
We now have a test for every merging edge case I know of, and
the roster_merge function appears to satisfy its defined interface in
every one of them. Hopefully that means all of them. I would _greatly
appreciate_ review of this code (in roster_merge.cc) -- it isn't
necessarily the nicest thing to read, I admit, but that just means it
needs review even more, to make sure it really is doing what it's
supposed to, isn't missing pieces, etc.
Three bugs and one oddity were found in writing them:
-- when there was an attr conflict, we correctly detected this and
appended a conflict descriptor to the roster_merge_result object,
but forgot to fill in the field saying which attr had the
problem. Oops.
-- roster_t::attach_node is supposed to fail if the place we want to
attach a node, is already taken by an existing node. This was
not tested for in the case where the place was the root, which
means that some strange csets would not crash monotone as early
as they should have. (As far as I can tell, the result would
still have failed the final "does our result make sense?" check,
it just should have failed instantly on the illegal operation
too.) This was actually discovered by accident... there is a
test for it now, though.
-- A missing early-return in assign_name caused the case where both
rosters have a winning candidate for the root node to be quite
broken; one of the nodes would end up still attached, which is
all wrong. Fixed.
-- Oddity -- there's some ugliness to roster_t's handling of
redundant operations. It's a little technical, I'll, uh, just
append the big comment I wrote, down below where only people who
are interested have to read it :-).
This was the last major blocker for 0.26. What remains now are:
-- documentation updates
-- attr documentation is wrong
-- manifest/revision format is wrong (in examples and in
the documentation of the formats)
-- tracking down and killing a few outstanding bug reports. Ones I
know of offhand are:
-- Grahame's report from 2 months ago that he couldn't
rosterify; it looks like Matt just tracked this down and
fixed it a few minutes ago on IRC.
-- Petr's problem pulling; I can't reproduce this -- I'll send
another email
-- the ticker bug with i18n locales -- I've seen at least two
reports of people running into this recently, and it's quite
nasty (monotone is basically unusuable without jumping
through hoops). We should get rid of it.
Please remind me of any other issues and regressions I'm missing!
-- writing release notes
I'm not aware of any real showstopper bugs; the buildbots have been
flaky lately, but I _think_ we don't have any real architecture/OS
regressions. Now would be a good time to speak up if you know of any
problem here, or anywhere else.
Cheers,
-- Nathaniel
--
Eternity is very long, especially towards the end.
-- Woody Allen
- [Monotone-devel] 0.26 status update,
Nathaniel Smith <=
- Re: [Monotone-devel] 0.26 status update, Richard Levitte - VMS Whacker, 2006/04/04
- Re: [Monotone-devel] 0.26 status update, Richard Levitte - VMS Whacker, 2006/04/04
- [Monotone-devel] Re: 0.26 status update, Lapo Luchini, 2006/04/05
- Re: [Monotone-devel] Re: 0.26 status update, Richard Levitte - VMS Whacker, 2006/04/05
- [Monotone-devel] legacy I18N and tickers (was Re: 0.26 status update), Graydon Hoare, 2006/04/06
- Re: [Monotone-devel] legacy I18N and tickers (was Re: 0.26 status update), BenoƮt Dejean, 2006/04/07
- Re: [Monotone-devel] legacy I18N and tickers (was Re: 0.26 status update), Nathaniel Smith, 2006/04/08
- Re: [Monotone-devel] legacy I18N and tickers (was Re: 0.26 status update), Nathaniel Smith, 2006/04/08
Re: [Monotone-devel] 0.26 status update, Nathaniel Smith, 2006/04/05