1.0 roadmap
Robert Collins
robertc at robertcollins.net
Wed Nov 21 06:50:34 GMT 2007
On Wed, 2007-11-21 at 17:19 +1100, Andrew Cowie wrote:
> On Tue, 2007-11-20 at 14:03 -0600, John Arbash Meinel wrote:
> > 9) I know Robert has some good ideas about how to evolve packs in the next few
> > releases. I would guess we would want to wait to make them the default until
> > after at least most of those have occurred. (Otherwise we will end up having a
> > recommended upgrade each month.)
>
> One of the biggest critiques levelled at Bazaar by the Git folks has
> been the instability of the data formats. While *you* and *I* know
> things are "fine" and that data has not been compromised, there was a
> lot of agreement with Keith's infamous comment about repository formats.
> I would encourage you, therefore, to get 'packs' stabilized before
> calling Bazaar 1.0.
One of the invariants of the world is change; Even the git format has
been evolving (in terms of what data they put in (e.g. subtrees
support), their index structure (AIUI the last release added better
handling of extremely large pack indices by a variable length
meta-index).
'packs' have a few key things to be done to be 'stable'. However there
is a bunch of things we have learnt that will (for instance) 1/2 the
size of a bzr repository on disk (and also network transfers). And as we
continue to learn we'll continue to make the knowledge we learn
available as improvements in bzr by issuing new formats that deliver the
result of that learning.
> If "large" projects won't consider Bazaar until the performance is
> "better"*, then no need to invite them to decide once and for all that
> Bazaar isn't up to it.
My understanding of the desire for 1.0 is that we want to signal that
bzr is /ready/ for use by projects that desire a solid VCS. bzr
certainly is that. If we were to say 'come ye hither projects of all
sizes and try us blind', then that would be silly... and irrespective of
packs, until the network performance is really bedded down, a serious
examination of performance will likely show up our latency-scaling
problems.
> AfC
>
> * is this really the case, or is it something else?
I know of at least one large (by history size) project that cares about
the version number more than performance; because our performance *is*
rapidly improving, but they see the version number as a indication of
seriousness/commitment to support.
> P.S. Why is it referred to as "knitpack" and not just "pack"? Couldn't
> you just call it "pack" in `bzr init-repo --help`? Also getting the
> default branch format with new branches to be whatever it's supposed to
> be and to clean out the cruft of the options like --weave and
> --metaweave and --dirstate-tags. (Comment from a serious freedesktop
> hacker used to using Git: "You have to use a special OPTION to make TAGS
> work in Bazaar?!?!? You're kidding, right?") No reason for that
> confusing stuff to be the first thing a user ever sees out of the help
> system.
Well, several things here. In bzr tags are on by default now. We try to
release a feature a release-or-two ahead of making it the default, so
that users that want to interoperate with older versions, which is
really the default behaviour in a networked work, can do so with no
issues.
As far as knitpack, I think its silly, calling it 'packs1' would be good
in my opinion.
-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/20071121/74ee151f/attachment-0001.pgp
More information about the bazaar
mailing list