Scoping the UI changes for 2.0

[Jason Earl]

Karl Fogel <karl.fogel at canonical.com> writes:

> Mark Shuttleworth <mark at canonical.com> writes:
>> Somehow, we have come to a point that the Bazaar community thinks it's OK for
>> there to be more than 10 formats "out there in common use", multiple
>> development formats (6!!), rich-root and non-rich-root formats, and all sorts
>> of bad interactions with network servers of various versions.
>>
>> During the 3.0 cycle, I would like to see:
>>
>> - a sprint and design focus on the command UI
>> - a commitment to having ONE stable format throughout, and ONE development
>> format EVER in 3.0,
>
> (Hope the below isn't a redundant point.  I read the rest of the
> thread to see if anyone else discussed this, and no one did, but it
> might be in another thread somewhere...)
>
> The issue is not that Bazaar has multiple formats.  Rather, it's the
> fact that users have to *care* about formats.  If Bazaar insulated
> users from format changes, then format changes wouldn't be such a big
> deal.

Actually, the issue is that Bazaar has multiple formats.  Really, it is.
I'll never forget the first time that I created a repository using:

bzr init-repo --format=1.9-rich-root --no-trees .

And then created a whole pile of branches in this repository using
fastimport.  I was shocked to find out that the various branches that
were created were in some crazy "unnamed" format.  I could stack on
these branches, but not without getting a warning.  A separate wire
format wouldn't help in this case.  In fact, it might even be
detrimental.  For example, the branches on the server could be in some
fancy new format (that my client supports) but branches cloned from the
server would probably still get created in the default format on my
machine, even if doing so didn't make sense.

A separate wire protocol would help launchpad, but I believe it will
help the rest of us far less than you think.  Branch formats are
everywhere, and unless you want to use the default format you have to be
aware of them all of the time.  The only way to fix this is to stabilize
the branch and pack formats and then stop futzing with them.

Both git and mercurial seem to have found formats that work for them.
bzr needs to grow up and marry its format as well.

> But because Bazaar's storage format is its wire format too, there is
> no intermediary protocol providing an opportunity for compatibility
> shims, and for graceful degradation of performance and even
> functionality.  Instead, if both sides don't support the same format,
> it's game over.

Once again, this only helps if you are using a smart server, and even
then it only really helps old bzr clients connecting to new bzr servers.
If you want to use a new format you'll still have to pay attention.
Otherwise you'll get the default format for whatever client you are
using.

I've said this before, but it bears repeating.  The real problem with
bzr is that it has a long history of using crappy formats, going clear
back to baz and arch.  Hopefully that's no longer the case.  If the new
brisbane-core format is *not* the format that is going to lead bzr users
to the promised land, then that is a serious problem that no amount of
compatibility shims is going to fix.

> When two formats are semantically incompatible then no intermediary
> protocol can fix that.  But many format changes are about performance
> more than semantics.  Bazaar often *could* translate one format to the
> other, but just doesn't do that.  Instead, it stops the show if one
> side doesn't support the format the other one requires.
>
> This is brittle.  True, it brings us a feature: you can push a branch
> to a location without a smart server listening at that location.  But
> we could retain that feature and still have smart servers do the
> appropriate compatibility translation when present.  The story would
> then be "If you want compatibility with as many Bazaars as possible,
> install a server."  Major sites such as Launchpad would, of course,
> use a smart server, so the most frequently accessed branches would
> also be the most compatible ones.

Alternatively, bzr could stop screwing around with its formats.

> Case study:
>
> Subversion's wire protocol is 100% unrelated to its storage formats.
> The wire protocol is extensible, and has been extended many times, but
> always backwards-compatibly: if a client or server doesn't upgrade,
> then at the most it simply doesn't get some new feature.  All the
> *old* features and behaviors are still there, and of course upgrading
> just one side still brings bug fixes.
>
> Thanks to this, there have been Subversion releases that completely
> rewrote storage mechanisms, and no user had to notice.  When this was
> done for performance reasons, the wire protocol hid the changes
> entirely: users don't know, admins don't care, ignorance is bliss.
> When done for feature reasons (i.e., there are semantic differences),
> there are still compatibility shims offering graceful degradation and
> admin-optional filters/blocking -- as opposed to completely
> disallowing communications from the get-go.

I'm pretty sure I had to care about formats when I upgraded to svn 1.6.
I also had to care about formats when my old bdb backend had permissions
problems.  Granted, subversion was less tricky than bzr, but I wouldn't
necessarily hold it up as a gold standard.

Plus, with subversion you basically had no choice but to install a
server.  A huge advantage of bzr over subversion is that bzr doesn't
require a server, and that even when you *do* have a server the server
is far less important than in a subversion setup.  If bzr continues to
have a plethora of formats then bzr users will have to worry about
formats every time they create a new branch.  With a DVCS, like bzr,
that happens quite a bit, even when working with a smart server.

Jason