On Tue, Jan 13, 2015 at 2:40 AM, Kelly Dean <[email protected]> wrote:
> Fossil's mistake here was in treating the thingy as a manifest, rather > than as a different type of artifact. > That approach could have doubled (some of) the code needed to handle manifests. Either way, the format is "fossilized," so there's little changing it now. I didn't mean to imply that anybody should care. I meant it in the sense of > ‟nobody cares how many licks it takes to get to the center of a lollipop”. > i haven't heard that reference in many years (not since leaving the States in the 90's). > > The hash proves (before each commit) that what fossil just wrote to the > db > > is what will be read back when the data is retrieved (if the check fails, > > fossil bails). It is "historical" in that it adds a layer of protection > > which has never (AFAIK) proven to be absolutely necessary (but is still a > > good security net when working on new fossil code). > > But that extra layer of protection doesn't appear to require the R-card. > That's why I said it looks redundant. It is redundant, in its own way, which is part of why it's been made optional in the meantime. > Even if you want that security net, you can still get rid of the R-card, > and Fossil's data format will still have the necessary hashes to provide > that security net. > The R-card is yet another safety net. AFAIK we've never seen a problem trigger there outside of (perhaps) while hacking on (lib)fossil's manifest generation code. > Specifically: > 0. The hash of every manifest M (which can be used to verify M) is stored > in every other manifest that mentions M, because the hash itself is used as > the name by which M is mentioned. In general, anywhere you mention a > manifest, you use its hash to do so. > 1. Likewise, the hash of every file F (which can be used to verify F) is > stored in every manifest that mentions F. > > IIUC, both #0 and #1 were true even when Fossil was first created. Yet #0 > and #1 combined make the R-card redundant. > So it appears that the R-card isn't just redundant now, but has always > been redundant. > True. Again, it was just an extra level of ensuring that fossil really delivers 100% fidelity. The addition of the B-card changed how #1 works (namely, that only changed/deleted F-cards are mentioned in the manifest which contains a B-card). > #0 alone make the Z-card redundant. > The Z-card is a separate check on the manifests contents, and isn't actually its blob hash: [stephan@host:~/cvs/fossil/fossil]$ f-timeline -n 1 checkin [df50cb6e4d56] @ 2014-12-18 23:27:57 by [stephan] branch [trunk] *CURRENT* fixed the mtime field on json timeline output. [stephan@host:~/cvs/fossil/fossil]$ f-acat current | tail ... Z 48e4e46f780886bd053e4b316397c965 i.e. df50cb... != 48e4e4... The Z-card serves not to identify the checkin, but to validate that the manifest itself has not changed since it was created. The R-card verifies (in its way) that none of the file content the manifest references has changed (barring the outlier case of hash collisions, which AFAIK we've never experienced in a negative way (only positive ones, where identical blobs share the same db record)). You might then ask, what if you never mention a particular manifest > anywhere? Well if none of your data ever mentions it, then obviously your > data doesn't depend on it. Which means you don't care if it's correct. In > fact, you might as well delete it. Fossil is designed such that it _does_ > always mention all your historical manifests (if it doesn't, that's a > Git-style design flaw), so you always have a way to verify them. > Fossil _never_ prunes data from a db with the necessary evil of "shunning" (a last-resort feature for removing potentially disastrous content like credentials and copyright violations). Fossil and git differ very much on how they treat history. > And if you want to quickly verify all your manifests without having to > walk your history graph to get all the hashes, remember you already have a > convenient cache of the hashes: they're stored as UUIDs in the blob table. > > Well then, simply cache a decompressed (i.e. not B-card-delta-compressed) > copy of each manifest (or at least, of some strategically chosen ones), > which enables a space-time tradeoff. ... > The NetBSD people would probably be happy to spend a few GB of disk space > on that cache in exchange for Fossil being fast. As with Fossil's other > caches and indexes, this would be built locally, not transferred over the > network when syncing. > So propose us a solution which doesn't break existing clients? -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
