[MERGE] mp-pack repo format

Robert Collins robertc at robertcollins.net
Fri Dec 28 07:35:30 GMT 2007


I'll dig into this in more detail when I return from work...

On Fri, 2007-12-28 at 00:31 -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> I've started work on a new repository format.  Ultimately, I expect it
> to use the mpdiff delta format, but that's not the focus of development
> right now.
> 
> My plan is to make a single method, _iter_texts, the underlying
> implementation of file text, revision XML, inventory XML and signature
> texts.  This allows us to retrieve any arbitrary set of texts from a
> repository in a single read.

I think having a 'access texts' api that takes key tuples may be a good
thing to do. I'd like to note that pack repositories can already do what
you talk about internally.

I think that the storage layer for byte sequences should be unified some
more (though it is pretty close to unified already - just needs some
more mapping work)... I wouldn't call the top level API _iter_texts
though, as many things will not be 'texts' in the sense we use it
elsewhere. And I definately do not think that having a single index is a
good idea, nor requiring two indices for object access.

> To achieve this, _iter_texts uses the prefixes 'file', 'revision',
> 'inventory', and 'signature' as namespaces to describe the kind of text
> requested.  This should also extend nicely to new types, such as
> 'annotation'.

I take it these are tuples - ('file', FILE_ID, REVISION) ?

> The VersionedFile interface would still be provided, but it would merely
> be a friendly API for services provided by the repository, including
> graph operations.

I want to see this happen too:
 - VersionedFile - per file graph data
 - Repository - access to texts, inventories etc.

> The format is still experimental, but I am posting it now to make sure
> that there's general agreement that this is the right way to proceed.

I would rather see a series of small patches that do cleanups in the API
of our current repository, and no new repository type in the short term.
I've found in the past that conflating API changes with disk changes
leads to big unwieldy patches that make it hard to reason about the
design.

I plan to add an experimental type for us all to hammer on, because I
have disk changes needed in the new year. I'll be happy to collaborate
on that experimental type with you as you add mptext stuff - though I'm
really quite unsure that mpdiffs are the right way to go for the bottom
storage layer.

> One option that seems interesting to me is to push these operations,
> including the graph operations, onto Store rather than Repository,
> because the original design of stores had them providing this data to
> Repositories.

I don't like this idea, the store concept has splits by type which
doesn't actually map to the physical constraints of repositories.

-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/20071228/cd02a820/attachment.pgp 


More information about the bazaar mailing list