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

[Stephen J. Turnbull]

Robert Collins writes:
 > On Wed, 2008-10-15 at 15:23 +0900, Stephen J. Turnbull wrote:

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

True, and it turns out that people who prefer git don't care about
the forced upgrade.  That's my entire point here.

My suspicion is that forced upgrades are no big deal as long as you
are very sure that the object database is safe.  The issue with bzr
upgrades is that they involve changing the database.  That's scary.

It's not "fair" to project another project's problems on to bzr, but
(to give one example) I know that Darcs has had problems off and on
with unreadable repos, to the point where they can't be checked out.
Except for the packs change, which happened quite early, AFAIK git
repos are all backwards and forwards compatible for project data and
basic history (ie, the commit DAG).  That's comforting.

 > [Subtrees] are an object type

But AFAIK they are *not* an object type; git's object typology hasn't
changed since the beginning of time.  Rather, AIUI they are
just a memo in .git/config.

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

Sure, but the error is just a missing object, and a bit of browsing
about by a human user will soon show what the problem is.  The same is
true of the various ways to #include an object database into a repo.

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

Precisely my point.  That's what I mean by stability, since it allows
me to recover much of the history (and certainly the parts I
personally consider most important) and all of the content by using
pretty much any version of git.

 > And a number of the bzr formats are likewise well above the 'odb'
 > layer.

But not all of them are.  That makes me, at least, nervous.

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

That's not the point.  You expressed a lack of understanding about why
there is a perception that git is more "stable" in some relevant
sense, and I'm providing my point of view about what that sense might
be.  I don't advocate that bzr go in that direction, and I think you
should be cautious about trying to compete with git on that kind of
thing.