Re: extensible metadata patch

Ok, now that the GPG work has landed, I've filed

Where I've started to clean up the sizes work.  I changed a few things
with the first commit:

* Make the checksum binary, not ASCII for space efficiency, and matching
  the other objects
* Change the sizes to unsigned 't' not signed 'x'
* Sort the checksums, just in case we want to bsearch on them later
* Drop legacy bits that were around to write a separate .sizes file; it
  is now ostree.sizes in the in-band metadata
* Add a test case (using the GJS-based tests it's a lot easier to parse
  GVariant data)

On Mon, 2013-09-09 at 16:05 +0100, Vivek Dasmohapatra wrote:
Let me know what you think!

As long as I can stuff the sizes data in there (has to be a pair of
size values for each checksummed object for my purposes, but I think
you knew that), I'm good  with it.

I originally didn't do so because I didn't want to break binary
compatibility but from skimming the bug you seem to have worked
around that.

With regards to your earlier comment about commits, I think we can combine the 
two approches: If we can harvest the commit size data as we do the commit,
for efficiency, as I do now, we can then use that cache as we traverse the 
commit so we only have to load filez objects to get the sizes out if we
dont have a cached value.

Has the advantage of being fast and simple when it can be but correct
for all cases, and won't normally trigger loading of all the filez objects
into memory.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]