Bzr development stopped

[Stephen J. Turnbull]

Chris Hecker writes:

 > > There's nothing to stop bazaar from keeping additional metadata
 > > needed to implement this properly, even if the git modules
 > > responsible for this refuse to change.
 > 
 > But then if somebody interacts with the repo using git and renames
 > something then the metadata won't be there, or will be out of sync, and
 > so it's not really a git backend really, etc.

If hitting your head with a hammer hurts, don't do that.  It's *not* a
front-end for git we're talking about.  It's more like using libxml
for handling XML.  If you don't use the appropriate DTD (metadata!)
when writing the document, you won't get a correct parse when you read
it.  Sure, it will be possible to manipulate the DAG with git.  It
will *not* be possible to correctly do VCS operations (not even "git
log -- FILE"!) with git on a Bazaar repo.  That's not a regression!

 > Is the goal simply to use the github ecosystem and whatnot?

"git" ecosystem, not "github".  You won't get correct information
based on non-DAG metadata from github without changes to github.
Those may or may not happen.

 > Because besides that, this seems like worse than sticking with a
 > format we control and is customized for bzr.  I mean, one advantage
 > of working with a less popular project like bzr is there wouldn't
 > be as much argument about what direction to take things, where if
 > we were on the git pack format, you could pretty much kiss making
 > any changes goodbye.

That's precisely why I think this is a good idea. :-)  Fiddling with
low-level content storage formats, like most premature optimization,
is lots of fun.  IOW, it's an attractive nuisance, a distraction from
what really needs to be done.

 >  Given that all my "dvcs 2.0" features that I want require lots of repo
 > format changes, this would make me personally sad.

On the one hand, repo format changes are a big burden for VCS
development because of the migration issue for users of old formats.
Every time Bazaar added a new format, the developers spent several
months just getting that right, and occasionally there were severe
performance regressions (for corner cases that were important to
somebody) that took weeks to months to work out.

On the other, I challenge your assumption that formats need to change
*at the level I'm talking about* in order to support new features.
The git storage format is about two things: finding content needed to
generate checkouts and/or diffs etc based on a static DAG, and DAG
manipulations like filter-branch.  git has proven to do those with
reliably high performance.

Finally, note that the git format is *extensible*.  That is, there is
space for a few more object types, if they're really needed.  For
example, tracking content at the subfile level would be possible by
adding a "file" type object, which would be mapped to names in "tree"
objects (as git currently does), but would contain not content data
(as "blob" objects do) but an *ordered* list of blobs (as tree objects
currently do, although in a tree object order is insignificant.  Such
a feature might be useful in refactoring, for example, where whole
functions or data structures are moved between files, or files are
split, etc..  I don't recommend doing this, but it would be possible
if necessary.

I don't know if this is the right path for Bazaar of course.  What I'm
looking for is a strategy that will reduce the burden of developing
new features, at the possible expense of some ugliness at the
"libgit"-Bazaar interface, and maybe some performance.

If you really need *both* the performance *and* the new features,
somebody is going to have to cough up real money, I think.

Regards,
Steve