[RFC] upgrade ordering & UI

John Arbash Meinel john at arbash-meinel.com
Thu May 14 15:24:14 BST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> Hi all,
> 
> I've made good progress today on a better upgrade command. If you want
> to test progress so far, grab a copy of lp:~bzr/bzr/smooth-upgrades. Of
> course, this is *not* production code yet so try it on *copies* on your
> data if you want to test it.
> 
> In particular, if you now pass upgrade the URL of a shared repo, it should:
> 
> 1. upgrade the shared repo
> 2. upgrade dependent stacked branches

How does it find the stacked branches? Search your entire hard drive for
anything pointing at $REPO ?

> 3. upgrade dependent unstacked branches
> 

> I'm planning to extend that with:
> 
> 4. upgrade (lightweight) checkouts under the repo referencing those
>    branches
> 
> Does that order sound right and should it always work? It seems to be
> working for 1.6 => 1.9 upgrading but it seems to fail for
> 1.6 => development6-rich-root upgrading. In the latter case, I'm getting
> an error (about an incompatible rich-root issue upgrading the stacked
> branch from memory). Is that an ordering issue or a separate bug do you
> think?

Stacking breaks when the serialization format changes. So you can go
0.92 => 1.6 => 1.9 => 1.14 (same repo), but you can't go 0.92 =>
rich-root, or 0.92 => dev6, or rich-root => dev6.

0.92 => 1.6 works because the only difference is a flag that we support
stacking. 1.6 => 1.9 works because it is just an index change, the data
stored is identical.

Everything else breaks because the data returned by
VF.get_record_stream([key]) would be different. (With inventories, at
least the 'format=X' line would be different, with CHK obviously there
are more differences.)

The 'fix' is to do stacking at the logical object level, where Inventory
objects are meant to be the same, rather than at the 'bytes' level.

> 
> On the UI front, I have some things I'd like feedback on:
> 
> 1. I'm planning to add a --clean option that will delete backup.bzr
>    for things that successfully upgraded. I think explicit is good here.
>    Does everyone agree? Right now, I do all the clean-up after all the
>    upgrades. Would progressive clean-up be better? I guess it is if
>    you interrupt things but it feels slightly less safe?

So personally I prefer the 'batched' style, where if everything
succeeds, then you go clean things up.

> 
> 2. Robert has asked for an upgrade to dev6rr to be followed by a pack.
>    Should that be implicit or an option? It seems to me that we ought to
>    clean out obsolete_packs iff we pack as part of upgrade and --clean
>    is given as an option. All agree?

It isn't as critical now as it used to be. InterDifferingSerializer
commits a write group every 100 revs, and that triggers an autopack
every 1000 revs. And autopack == pack.

That said, if you have 50k revisions, then you end up with 5 10k packs,
which are quite a bit smaller as 1 50k pack. dev6 has slightly more
overhead for lots of pack files, because it always stores a fulltext,
rather than allowing cross-pack deltas. We could change that, but we
would need to find cases where it is a real problem. As it has some very
nice safety properties.

> 
> 3. I've suggested a --find option to search for repos/branches/checkouts
>    to upgrade. I think that will be good because it allows upgrade to
>    smartly order things, e.g. stacked before unstacked. Another option
>    though is for upgrade to take a list of directories to upgrade. That
>    seems more flexible but it then requires a separate command to find
>    those directories and optionally intelligently order them. Any
>    preference on direction here? (It will be a follow-up patch
>    regardless.)
> 
> Ian C.

I would say give a list of directories to recurse, and do the smart
ordering internally. So if you give path/to/repo it will find
repo/branch1, but doesn't try to look for /tmp/foo/stacked unless you
give 'bzr upgrade path/to/repo /tmp/foo'.

I think the logical ordering needs to be done by bzr itself, since it is
a dependency chain. (Potentially you can stack another branch on your
stacked branch, ad infinitum, though anyone using > 1 hop is asking for
trouble.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoMKY4ACgkQJdeBCYSNAAN3ggCg1o3cPCXf9sUl4lKe8qyEqOew
+54AnRT+bEQ04l0UDg/jsciuR8bP5L4X
=kZZ4
-----END PGP SIGNATURE-----



More information about the bazaar mailing list