No subject

         I was able to reproduce this overnight - the import failed
         after 55500+ revisions. I got a different file though
         triggering the issue: lisp/gdb-ui.el. I'm tracking down the
         exact revision triggering the bug today.

         On the bright side of things, I was able to get all 105K
         revisions imported into a brisbane-core format last
         night. That's because fast-import uses a different algorithm
         (building an inventory delta & applying it vs in-place
         inventory mutation) for the new formats. That suggests the bug
         is in fast-import itself, not bzr or the data stream and it
         shouldn't be hard to isolate.

I originally thought that the bug was due to changes to fast-import, but
I was able to trigger the same bug in revisions in my own branch that I
*know* used to import the repository.  The git repository changes quite
a bit (including surgery done in git to add merge information after the
fact) so my guess is that the bug has actually been in fast-import for
some time, and the logic used to create new format repositories simply
doesn't trigger it.

So yes, I did grandstand a bit with my example :).  The fact that the
import works in the brisbane-core formats is more a result of the fact
that the new format makes the code for fast-import a little bit more
straightforward.

This doesn't change the fact that the energy of the bzr development team
is focused on brisbane-core.  That's the future, and it is apparently
not a far distant future either.

>> > NOTE: I think the Bazaar developers would like to know, too, so
>> > I've set Reply-to on this mail to go to the Bazaar list.  The
>> > thread would get off-topic for emacs-devel at this point anyway --
>> > anyone who does a follow-up-to-all, please take emacs-devel@ off
>> > the recipient list.
>> 
>> Hopefully the bzr development team really did want to know about this.
>> If not please excuse me.  I am a huge fan of bzr, and I really think
>> that the project is on the right track.
>
> Its really encouraging to hear this, particularly right after Python's
> decision. We've been doing monthly releases for a long time now, and I
> really like the rhythm it gets us, and the confidence to get things
> out there for users [with a small caveat about things with
> persistence, which I at least am more sensitive about].

Bzr has some very tough competition, and I really think that the project
started at a bit of a deficit.  However, the Bazaar project is clearly
covering a *lot* of ground, and your release schedule is a big part of
that.

> I think that moving to bzr/0.92-pack would indeed be problematic for
> emacs, as it would likely impose a painful performance overhead on
> enough operations that we'd be getting hate mail :(. However, the 1.14
> beta format should really be sufficient for final planning and
> analysis for a migration.

Is 1.14 the new brisbane-core format?  If not, then I disagree.  Moving
Emacs to a format that is going to be replaced in a few months only
guarantees that the Emacs developers will experience pain in the future.

Even if 1.14 is the brisbane-core format the fact that it won't be the
default format is problematic enough.  For example, I ran into issues
where I created a repo like:

bzr init-repo --format=1.9 foo

When I created branches in my fancy new repository instead of 1.9 format
branches I got default format branches. Interestingly enough I could
still stack branches on these unnamed format branches, but I got a
warning message that made it seem like it wouldn't work.

It was easy enough to write a bit of python that used bzrlib to upgrade
the branches, but that's precisely the sort of thing that makes it hard
to sell bzr.

Don't even get me started on the rich-root variants.

In short, lots of releases is fine (in fact, it's probably necessary if
you want to compete), but the on disk formats *really* need to
stabilize.  Hopefully brisbane-core will put paid to this issue soon.

Jason