some comments on bazaar-ng

[Martin Pool]

On Wed, 2005-04-13 at 14:42 +0200, duchier at ps.uni-sb.de wrote:
> Denys Duchier <duchier at ps.uni-sb.de> writes:
> 
> > I was also initially confused by .bzr because I expected to see something like
> > patches somewhere in there, except there aren't any.  That's the "compressed
> > storage" issue, I gather.

Many delta-compression designs turn out to perform well in some ways but
badly in others, so I've deferred adopting one until I'm sure it will do
reasonably well.  I think the revfile design is probably close to being
right, so it will go in shortly.

> On this issue, I have a few thoughts.  Of course, I am probably retracing design
> ideas that you have already entertained, in which case, I hope you'll bring me
> up to speed gently ;-)
> 
> The way I'd like to factorize things is:
> 
> - an archive should have a chronological record that consists of changesets
>   containing forward deltas

Storing deltas for whole changesets is rather less flexible than storing
deltas per file, and not really better in any way.

> - bzr should depend on what I'll call a "revlib service" for its operations.  a
>   revlib service, once pointed at an archive's chronological record, provides
>   convenient access to all its revisions (convenient for the operations that bzr
>   needs to perform).

There are important internal objects (RevisionTree, etc) that do exactly
this, allowing most of the code to ignore the details of how the
revision is stored.

It is somewhat less useful to have the revisions stored on disk, as Arch
does.  (Well, I suppose partly that's because on-disk trees *are* the
object model for shell script, so breeding will out.)  More precisely, I
don't think the value of having them justifies the work and disk IO to
build them.  It might be useful to provide such a tree to an external
tool like dirdiff.

>   the current bzr code base already contains (most of) one possible
>   implementation of such a service using auxiliary data stored in:
> 
> 	./bzr/inventory-store
> 	./bzr/revision-store
> 	./bzr/text-store
> 
>   note that, if this is factored out as a revlib service, there is no need for
>   the auxiliary data to be stored in XML; you might as well use cPickles.
> 
>   Of course, there could be alternative implementations of revlib services,
>   e.g. using subversion fs, either running in the bzr process or delegating to a
>   server, etc...

> Is this completely foolish?

Not at all.

-- 
Martin

-------------- 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/20050415/5d8bb62f/attachment.pgp