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

[Robert Collins]

Sorry for taking so long to reply; I wanted to dig up the right answers,
and time got in the way.

On Wed, 2008-10-15 at 19:36 +0900, Stephen J. Turnbull wrote:
> 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.

Ok. Perhaps we have quite different userbases to git; I know we have had
many users complain when we *contemplated* forced upgrades in the past.

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

Depends on the upgrade; one thing we may want to improve is the
messaging about the risk of running any given upgrade. 

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

git, like bzr, is not bidirectionally compatible even at the data level
(that is if you force everything to loose objects you still don't
guarantee an older git can read your tree, depending on what you've done
with it). I've included a quote from gits 1.5.2 release notes below
which supports this statement.

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

"* Plumbing level superproject support.

  You can include a subdirectory that has an independent git
  repository in your index and tree objects of your project
  ("superproject").  This plumbing (i.e. "core") level
  superproject support explicitly excludes recursive behaviour.

  The "subproject" entries in the index and trees of a superproject
  are incompatible with older versions of git.  Experimenting with
  the plumbing level support is encouraged, but be warned that
  unless everybody in your project updates to this release or
  later, using this feature would make your project
  inaccessible by people with older versions of git."

And the key point is the last one:
 - using the subproject feature makes your code inaccessible to folk with 
   older gits



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

I think missing object errors are really not that easy to debug for an
average user; for someone used to working with databases of various
kinds - sure; but a graphic artist, or a documentation writer, or
project manager - no way is that easy for them.

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

See above though - you have a perception about git that isn't true. It
is true that if you are careful about the features and capabilities you
use you can force things out to a disk layout an older git will read,
and then use that older git; thats true about bzr as well though - you
can export even the most modern bzr formats out to be read by bzr as far
back as 0.8 (for anything bzr makes by default) or 0.15 (I think) for
the bzr-svn support.

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

Thats fair enough; I don't think that the odb level is 'finished' in
bzr, hg, or git. I recall a git changelog not that long ago that changed
the index layout in git packs - thats right down at the level that makes
you 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.

Thank you for providing input here; I think I have more information on
the topic; though I suspect my conclusions may still differ from
yours :).

-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/20081024/b2870663/attachment-0001.pgp