Re: [Monotone-devel] Please review nvm.automate_get_roster

[Thomas Keller]

Am 05.10.2010 12:28, schrieb Markus Wanner:
> Hi,
> 
> On 10/04/2010 02:32 PM, Thomas Keller wrote:
>> Please review the above branch. The branch name has not so much in
>> common with the actual implementation anymore, though:
>>
>> * a new file_sizes table has been added which records the size
>>   in bytes of individual files
> 
> Per revision of each file, that is, right? Or what files?

Right, per individual file version. Since we store full files and file
deltas, the id of the file_sizes table joins with either, files and
file_deltas.

>> * two new automate commands have been added, get_file_size returns
>>   a single recorded file size, get_extended_manifest_of returns
>>   a format similar to the current roster format, but without the
>>   local node ids. Additionally, the format prints out the recorded
>>   file size for each file node
> 
> I like the get_extended_manifest_of thing, but what's the use case for
> the file size? Shouldn't that rather be part of the roster, for example?
> (It's easy to see the file size as a cacheable attribute).
> 
> An extra table which adds yet another place to lookup sounds rather
> wasteful to me.

I tried to include the information into the roster at first, but this
would have made the implementation far more complex than initially
anticipated. The underlying problem is that we have different notions of
rosters, some are created out of the database cache, some are build
dynamically from workspace contents, some are the result of merges
between both forms. This code was very hard to understand and even
harder to tweak for me and I'd have to make many changes in areas I did
not really feel "safe" about.
So the restriction the current implementation has because of this
separation is that it cannot output artificial rosters / workspace
rosters with file sizes, but only existing cached database rosters, but
given the fact that one could use "au inventory" for a workspace use
case, this is not a big loss IMHO (one could easily append the original
file size of existing / missing files here now as well though).

In the end I'd rather see a roster-only implementation of this as well,
but I'm afraid I'm unable do this.

> What's the use case for getting file size information exclusively? I
> haven't ever needed just the size, but not the real data.

Patrick already answered this.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature