[Monotone-devel] status of mainline

[Nathaniel Smith]

Two biggish changes on mainline this weekend:

Root rename handling landed.  The most user visible change is that
'rosterify' now works on histories where multiple independent imports
were merged.  In addition, the perverse among you may find enjoyment
coming up with strange things to use the new "pivot_root" command for.

Blobs landed on mainline[1].  I was only holding off on this because
it might be destabilizing before 0.26, but 0.26 is taking a bit to get
here and it's a pretty safe branch, so here you go.  For those
following alone, upgrading to this from an earlier roster-enabled
monotone will require a 'db migrate' (but netsync, etc., are all still
compatible).  This is the .binary version, not the .binary.zlib
version that Matt J. put together that includes switching to pure
deflate from gzip... that branch would have broken packet
compatibility (including, AFAICT, all private keys!), and caused a
netsync version number bump, which would just be a bit tiresome.
We may still integrate this later; schema migration is not too urgent,
since it doesn't effect interoperability...

[1] Not this kind: http://www.imdb.com/title/tt0051418/

The root renaming thing was one of the 2 major blockers on a full 0.26
release.  The things I can think of remaining to figure out:
  -- exhaustive roster_merge tests -- see roster_merge.cc for list of
     what's needed.  (I've been picking away at this, but help would
     definitely be appreciated, since this is the biggest piece
     missing.)
  -- tracking down Grahame's rosterify problem:
       http://article.gmane.org/gmane.comp.version-control.monotone.devel/5927
     (No-one's working on this, AFAIK.)
  -- doc updates -- we currently misdocument the revision and manifest
     formats, and attribute documentation is also wrong.  (Dan
     Carosone may be looking at this.)
  -- utf-8 validity checking on filenames.  This means, in the
     general path sanity checking, adding new checks to make sure that
     the paths we deal with actually _are_ utf-8, like they're
     supposed to be.  This is one of those changes that has the
     potential to break -- or at least, reveal previously unnoticed
     brokeness -- in real trees.  We know that there are bugs that
     make it possible to break things this way; we don't know if
     this has happened in the wild.  (Matt G. has some work done on
     this.)
  -- possible shortening of the executable name, and general
     normalization on this name.  This is probably controversial; I'll
     send another email about it :-).

The new root rename handling and the utf-8 validity checking are the
two things I'm most worried about causing or revealing new problems.
Maybe if the utf-8 validity checking stuff goes in soon I can release
a pre3 for them to get a bit more testing...

-- Nathaniel

-- 
"If you can explain how you do something, then you're very very bad at it."
  -- John Hopfield