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

[Stephen J. Turnbull]

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).  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.

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.

 > 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.

 > 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.

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.