monotone-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]