Re: Bzr switch

[Robert Collins]

Sorry for breaking the thread; I'm not on this list, and my mail client
doesn't seem to have a 'lie about history' field.

> From: Stephen J. Turnbull 
> Date: 2009-06-29 23:37:53 GMT
> 
> Karl Fogel writes:
> > Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> > > In the Bzr world, there's always something new coming up providing this
> > > and that performance improvement.  So there's no point waiting for the
> > > next one, cause when the time is passed, you'll end up wanting to wait
> > > for the next next one, etc... ad nauseam.
> > 
> > I understand what you mean, but This Time Is Different (or so I am told,
> > in no uncertain terms, by every Bazaar developer I talk to).

I think it is different. One thing that 2a gives us is *breathing space* -
until now we've been playing catchup - everytime we improved performance,
another group of users would pop up and say 'we want to use it, but damn its
slow'. We're not finished - thats true, be we are now definitively over the
performance hump. We haven't really promised to keep format changes out of
the way in the past - and we've had a lot of pressure to deploy every single
incremental improvement we made. We haven't changed the default format since
Octobert 2007, and it's my hope that the performance wins in 2a will let us
focus on higher level things that core history storage for the next

Some reasons to use 2a rather than 1.9 or 1.9-rich-root.

For starters, in 2a we've dropped all support for non-rich-root flavour,
letting us finally put behind us a very early design defect in bzr.
Using the 1.9 format would require emacs to migrate past that change -
but its better and more efficient to start with a rich root format
(which 2a is).

Secondly, much of the performance improvements are obtained by using a
better representation for the hash that contains versioned file data in
a revision; 1.9 is _massively_ slower than 2a, and doing the conversion
is inordinately time consuming (even though its simple to do, its
hampered by having poor source format performance).

2a is approximately 1/3 the size on disk for most projects, which also
adds to performance, by requiring less data transfer, less cache
footprint etc. 

And 2a is supported. Its not going to get changed at this point [barring
unforeseen critical issues], and we expect to keep it as-is for the
entire bzr 2.x cycle.

I heartily endorse the use of 2a because it will be better, faster, use
less memory and provide a nicer environment. 

>Who are you talking to?  The list traffic tells a very different
>story.  Mark Shuttleworth (Da Beeg Boos) wrote "Thou Shalt Have But
>One Bazaar 2 Format", and got *lots* of pushback.  AFAIK he gave up;
>the Bazaar devs surely act like that pronunciamento is "inoperative".

Mark has asked us to fix the current UI headaches that have emergerd -
some of which we painted ourselves into. One aspect of that is getting
rid of the huge list of formats, and another is not creating that 
problem again. I don't think Mark has given up his desire for us to fix
this. What he has done is acknowledged is that fixing the UI requires
some care and thought - and that with the dev team focusing on the
plumbing changes to really put performance issues to be the cycles
simply are not there to address the UI before 2.0, *or* we delay 2.0
(which primarily consists of changing the default output format to 2a
and thus giving everyone a radically better experience). I don't think
anyone is keen about delaying 2.0 once we've got all the things in
place for changing the default. That list is pretty short now - one
or two server tweaks, some remaining performance work mainly targeted
at the migration process and finally some assistance for people
migrating.

> Robert Collins is *not* on board on "2a", specifically, looms are not
> included in 2a, which means at least two variants of 2a will be out
> there in the wild for a while.  (Silver lining: looms are usable as a
> local improvement, you don't actually need them on the server for many
> common workflows.) 

Looms have never hooked into the history storage layer (which is what 2a
is all about). Fixing the root cause for the UI friction I refer to above
will likely bring in sufficient core capabilities that loom can stop being
a separate branch type - this has been touched on a few times on the list
I think. If not, I'm fairly sure its in the devnotes branch.

> Aaron Bentley is *not* on board on "2a",
> specifically nested trees have not landed, but they will.  (Emacs
> doesn't care, I think, but many projects want nested trees very badly.
> It will land, not before 2.0, I suspect, but not too long thereafter.
> This will mean a server upgrade, the formats are mutually incompatible
> currently AIUI.)  Four variants.  And counting---don't kid yourself,
> there will be more.

Nested trees are unlikely to hit 2a, they need to be ironed out, transient
code needs to be fully migrated, performance will need to be assessed and
so on. I'm keen to see them completed because they are an important feature,
but its not done till its done.

In short - there is 2a, looms for people that want to use them sit on top of
2a today, and nested trees are not finished yet.

We do need to find a way to gradually deploy such things; all VCS systems do
this, at different rates and in different ways. I'm sure bzr doesn't have the
tradeoffs right yet :(. 

> IMO (and that of the Python devs, see PEPs 374 and 385), Stefan is
> right.  You need to settle on a version that's either Available Now or
> Coming Soon To A GNU/Linux Distro Near You.  People who want to bleed
>can always do that (to) themselves. :-)

I heartily agree - pick a single format and release of bzr, get using
it. That format should be 2a.

-Rob

signature.asc
Description: This is a digitally signed message part