Serializer_v5._pack_revision and _unpack_revision to become public?
David Allouche
david at allouche.net
Tue Jan 17 00:06:58 GMT 2006
On Mon, 2006-01-16 at 09:56 +1100, Robert Collins wrote:
> We're deprecating all the XML facilities anyway. So : what does your
> extension data look like? Would a black-box storage mechanism that lets
> you do much the same thing suffice?
The bzrk cache I am using is a XML file store in .bzr/x-bzrk-revisions.
It is read using Branch.controlfile and written using the same
combination of Branch.controfilename and AtomicFile as .bzr/parent.
Its format looks like:
<collection>
<revision yadda yadda>blah blah blah</revision>
<dummy revision_id="jabberwock"/>
...
</collection>
<revision> and <dummy> items are unordered.
The whole file is read and written using elementtree classes imported
from bzrlib.xml (to reuse the import logic that uses cElementTree if
it's available).
The <revision> elements are created and processed using _pack_revision
and _unpack_revision.
The <dummy> elements are used to record which revisions were previously
found to be ghosts (there is a "bzr vis --ghost" option to ignore
<dummy> elements when reading the cache).
The requirements for the cache are the following:
* Fast to read and write. cElementTree is fast at reading, but
still seems to use a Python implementation for writing. I would
like no slower reading and faster writing.
* Safe to use with data that is no more trusted than any branch
data than you can find anywhere on the internet.
* Allows embedding of blackbox bzr data in a foreign data format.
I do not care how revisions are stored, but I want to mix them
with my own data.
--
-- ddaa
-------------- 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/20060117/12a2a698/attachment.pgp
More information about the bazaar
mailing list