[Monotone-devel] Status update

[Nathaniel Smith]

On Wed, Nov 17, 2004 at 01:17:46AM +0800, Matt Johnston wrote:
> On Tue, Nov 16, 2004 at 03:27:22PM +0100, Joel Rosdahl wrote:
> > Nathaniel Smith <address@hidden> writes:
> > 
> > > [...]
> > > Whee:
> > >   $ monotone pull joel.rosdahl.net net.venge.monotone
> > >   [...]
> > >   monotone: fatal: std::logic_error: netsync.cc:565: invariant 'I(j != 
> > > attach_map.end())' violated
> > 
> > Yeah, I've been hit by this too. I've filed bug #10981 on Savannah for
> > it.
> 
> It appears to be caused by the "break;" in netsync.cc:610,
> which shortcuts the loop, skipping a call of
> analyze_attachment() for some additional parent revisions.

After a nice evening of collaborative debugging on IRC, I can say that
this is correct.  Apropos, status of a bunch of monotone stuff:
  - This bug turns out to be the same one that's preventing off.net
    from picking up my changes; with 0.15 netsync if you have shared
    history from a previous netsync, then it becomes impossible to
    send merges over netsync.  The change Matt gives fixes this
    problem.
  - Since the bug in netsync makes it kind of hard to get the fix,
    I've stuck a latest-and-greatest monotone
      http://www.fresco.org/~njs/monotone.bz2
    This is a linux x86 executable compiled on Debian testing with
    boost statically linked.
  - If Graydon is busy with his conference tomorrow and doesn't get
    around to upgrading off.net to the latest-and-greatest, then
    I'll push into someone else's upgraded always-on server and we can
    work from there for a while; the current situation is kind of
    silly.
  - My repo also has fixes for the problem where you can't merge
    unrelated revisions no matter what (0.15 tries to use the null
    revision as a common ancestor, and crashes), and a bunch of added
    tests, some of which even pass.
  - Currently there are two heads for .changesets, the ones from me
    and from Joel; excitingly, this is our first real criss-cross
    merge!  Unfortunately, what this means in practice is that merging
    is really annoying, because the common ancestor chosen is
    sufficiently high up that one has to merge ~280 conflicts in
    documentation tweaks by hand.  Well, at least that's what ediff
    claims; ediff also gets out of synch and starts giving huge
    spurious conflicts, though, so another tool might do better, I
    dunno.  I am wondering though if this means it's time to add a
    'monotone merge [left right [ancestor]]' command, and whether that
    would help...

-- Nathaniel

-- 
"But suppose I am not willing to claim that.  For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."