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 | tommyd3...@jabber.ccc.de | 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
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel