some comments on bazaar-ng

[duchier at ps.uni-sb.de]

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.

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

- 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).

  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?

Cheers,

--Denys