observation about trac+bzr and bzr smart server with big repo

[Robert Collins]

On Wed, 2008-10-15 at 15:23 +0900, Stephen J. Turnbull wrote:
> Robert Collins writes:
> 
>  > I appreciate that bzr has had a few formats, and don't want to add
>  > things that will confuse users for the sake of confusing users ...
>  > however the perception here is also skewed by a certain misperception
>  > regarding git and hg here: By a loose count git has had at least three
>  > format changes where newer clients generate data older clients cannot
>  > cope with the repo (packs and subtrees);
> 
> Packs are optional, and are simply storage media anyway (ie, it's
> like adding a new compression method to tar).

git before packs cannot use a git repository that uses packs - it
doesn't know how to get at the data. This doesn't say anything about how
deep a change packs where, but they *were* a change that forced an
upgrade.

>   Packs could easily be
> exploded if necessary, as the object database has not changed.  I
> would imagine subtrees are optional, too, and I haven't looked but I
> would be willing to bet that they do not involve a change in the
> schema of the abstract object database.

They are an object type that clients from before them don't know how to
handle; git marks each object individually, which is a little different
to bzr, but as git strongly encourages a single db per project, this
just means that users encounter the error late rather than early.
alternates are another git feature not present right at the start that
will confuse clients that don't support them.

> This is different from the semantic changes involved in bzr's format
> changes, and which I suspect would be involved in a format change for
> hg.

bzr's format changes have ranged from being just as shallow as gits (the
introduction of bzr's packs did not change compression, object graph,
digital signatures or any other aspect of the model), to being
substantially deeper (the split inventory work is in some ways the
deepest).

>  > Generally users should not need to worry about the formats [with one big
>  > glaring exception(*)].
> 
> And bugs.  Every format change introduces the possibility for new
> bugs.

Of course. And the changes in git listed above have the possibility for
bugs too.

>  > They are essentially internal except where a new feature requires a
>  > semantic change (and thus a new format).
> 
> But AFAICS git has supported lots of new features without semantic
> changes to the ODB.

I think it depends on how you define semantic change. Gits object
database is so low level that nearly any change you make won't affect
that layer, any more than adding a new compressor to tar will affect the
record creation and reading code. And a number of the bzr formats are
likewise well above the 'odb' layer.

> It may be that git *cannot* for that reason support some of the
> features that bzr does, but apparently git's fans care a lot less
> about those bzr features than they do about git's well-deserved
> reputation for speed and its ODB schema stability.  I know I certainly
> feel that way, though I need to use bzr for some projects.

git is certainly very fast; I challenge the claim about schema
stability; I think a matter of where you place the goalposts and do the
measuring from.

If we measure stable by 'version X and Y can parse and process every
object in the repository' git has most definitely undergone changes fail
that measurement.

That in no way detracts from the smooth experience apparently felt by
users of git - and not having to 'reload' their local database to add a
feature may contribute to that feeling. Its possible for upgrades in bzr
to do that too - but its not the default, because the generic upgrade
code doesn't know what its upgrading - it defaults to just doing a pull
which will migrate anything that needs migrating.

Anyhow, I really don't want to get into a pissing contest on whether bzr
has done more-or-less changes than svn|git|hg; bzr has had more changes
than I think is strictly desirable, but changes are still worth doing
when there are improvements to offer to users. IMO git, hg and svn all
have made changes at various levels of their stack - physical storage,
network, tree model.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081015/c9628428/attachment-0001.pgp