more performance work?

Jelmer Vernooij jelmer at samba.org
Wed Nov 7 19:45:36 GMT 2007


Am Donnerstag, den 08.11.2007, 06:03 +1100 schrieb Robert Collins:
> On Wed, 2007-11-07 at 19:47 +0100, Jelmer Vernooij wrote:
> > Where would you specify what merge algorithm should be used for a
> > particular file?
> What I have in mind would use a local config or a heuristic - e.g. each
> merge type can probe and decide. This is simpler as a first cut and
> doesn't preclude a versioned config eventually.
Ok, makes sense.

> > > What I'd really like to point out here is that *storage* of the data for
> > > a feature is -not- why we have format bumps.
> > > 
> > > We have format bumps to ensure that the new /logic/ required to
> > > correctly process the data of a new (or add-on-supplied) feature, is
> > > present, when the data is, so that old versions don't mangle (by either
> > > inaction or action) the logical state of that feature for the version
> > > that introduced it.
> > For all of the features specified above, I think they can all be
> > advisory - in other words, it's ok if the data is present but ignored by
> > older versions of bzr. For example, for line endings, it's the advised
> > format in which the data should be stored. 
> Well, for line endings, I think its a disastrous idea to store differing
> versions commit after commit - very much not advisory. History size will
> grow ridiculously, and diff will not DTRT if it is advisory.
Ok, so maybe line endings are a different story (perhaps convert on read
and use an eol-type-indifferent diff, like Mercurial's filter feature?).
I don't see any reasons why that's the case for tracking cherrypicks,
tracking copies or keyword expansion though. 

> > > file properties as a way to consolidate/reduce duplication of effort in
> > > the serialisation of data are a fine thing. But they *don't reduce
> > > format bumps at all*.
> > This means there are a lot of format bumps ahead (presumably watershed
> > upgrades?).
> Lots of features which can only come in on format bumps. Watersheds
> should only occur when a feature has been used in a tree - until then
> exporting to a down level repository should be possible. (Rich roots
> hasn't been done this way, but I don't think this applies to the other
> features we listed).
Watershed format bumps are bad, especially since you have to upgrade the
full repository. A new format isn't really usable for the public
branches of your average FOSS project until it's supported by a version
of Bazaar that's in the releases of the major Linux distros; otherwise
regular users, running the bzr that came with their distro, can't check
out those branches. 

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
Jabber: jelmer at jabber.fsfe.org



More information about the bazaar mailing list