Scoping the UI changes for 2.0

[James Westby]

On Tue, 2009-04-28 at 10:19 -0400, Karl Fogel wrote:
> 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.
> 
> 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.

Hi,

Thanks for the comments, I think this is a move in the right direction.

I originally read your comments differently, and so thought you had the
wrong idea, but I think I now see the intent of your proposal.

bzr already maintains the ability to read old formats, and this works
transparently up until the point that it starts telling you to upgrade.
The only case when this becomes a problem is when you have rich-root and
non-rich-root or similar (which will go away, but will be quite a big
headache as 2.0 rolls out I fear).

However, your intent is to allow the source side of a network 
communication to be using a much newer branch format, regardless of
which clients support it. This means that the server could keep all it's
branches in the latest format without the clients having to care, 
leading to new users getting the best experience by default.

I think this would be great, but is only really one side of the issue.
There is also the side dealing with formats locally. At some point bzr
will tell me to upgrade my branches, and then I have to start messing
around with formats some, and you start to hit some UI warts. Plus, the
upgrading messages themselves can be very irritating, given that you
may not have control over the branch.

While having a smart server that can transcode as needed makes the
decision to upgrade easier, it is not everything. Cases that must still
be considered are dumb servers (http is certainly still going to be 
widely used, and ftp won't be going anywhere), NFS shares, and other
arrangements that mean you may not have mixed clients accessing the
branch.

Therefore while either proposed solution will help with this I feel that
improving the experience around formats would be beneficial anyway.

Some suggestions from the top of my head:

  * Attempt to warn the user about an outdated format once a day at
    most. Make the warning point to a help topic that explains the 
    issues involved so that they understand what it will mean.

  * bzr has moved to using version numbers instead of features in format
    descriptions, which is a great step forward, but could be improved
    upon. The version numbers indicate the minimum bzr version you
    want to be able to access the branch with, so why not make that
    explicit. "bzr upgrade --min-version=1.6", and bzr satisfies your
    request.

  * upgrade should work better when you use a shared repo. When you are
    informed that you should upgrade your shared repo it says "run bzr
    upgrade", which you do and it says there is nothing to do. You then
    try and carry on with your work, and it says it again, when what it
    means is "run bzr upgrade in the root of your shared repository".

  * When you have a rich-root source, and want to pull in to a shared
    non-rich-root repo it tells you to "run bzr upgrade" you do, and it
    tells you that there is nothing to do, and yet your command still
    fails. You need to work out that you should be using "bzr upgrade
    --default-rich-root" (if your client is new enough to support that
    alias). Perhaps instead you should be able to say
    "--compatible-with other-branch" and have it work it out for itself.
    (Less of an issue with rich-roots-by-default, but it will be a while
    until everything is rich-root).



Thanks,

James