Bzr development stopped

[Chris Hecker]

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

This was sort of my assumption as well, I just hope that if I get the
money part, there will be bzr developers around to take it in exchange
for features!

Chris


On 2012/11/27 23:30, Stephen J. Turnbull wrote:
> 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
>