So many repo formats
John Arbash Meinel
john at arbash-meinel.com
Mon Nov 17 22:37:21 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Stefan Monnier wrote:
>>> So, what's the downside?
>> Upgrading from a non-rich-root format to a rich-root format is more
>> resource-intensive and one-way (you can't convert from a
>> rich-root-format to a non-rich-root-format, since that would lose data).
> I don't understand why its one way: losing data is usually the easier path.
Because going rich-root => non-rich-root => rich-root would not yield
the same data (introducing subtle inconsistencies and seeming
corruption), we don't allow the path.
>> Also, bzr versions before 1.0 don't support any rich root formats.
> But these don't support the 1.9 format either. So it looks like the 1.9
> format is simply useless and should be killed right away, and the
> 1.9-rich-root should be renamed "1.9".
The biggest reason to allow for --1.9 without -rich-root is because
going through rich-root is a one-way operation. Once you've upgraded,
you cannot submit your data back to a non-rich-root repository. So we
want the user to explicitly request it. You can go back and read the
threads about 1.9, as we did propose that at one point.
As it stands, 1.9 has significant benefits over 1.6, and we didn't want
to tie those benefits strictly to requiring *everyone* in a given
project to upgrade to a rich-root compatible format.
As it stands, if *you* decide to upgrade your branches + repository to
1.9 to get the benefits, it is still fully compatible with someone using
bzr 0.7 and Weave format branches. (You'll get deprecation warnings
pushing to a Weave branch, but it still *works*.) Once you upgrade to
rich-root, you are no longer backwards compatible with weave, knit,
pack0.92, etc repositories.
Having rich roots is marginally better, but at the moment the benefit
doesn't quite justify the backwards incompatibility.
That said, if we *really* wanted to push out rich-roots, then we should
upgrade bzr.dev to 1.6.1-rich-root, causing all of us to upgrade our
repositories, which then spreads to all of the other projects we use in
our shared repo (I keep a lot of plugins together), etc. I'm not
particularly fond of "flag day", but if we want to do it, we may as well
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar