On Sun, Jan 4, 2015 at 5:29 AM, Kelly Dean <[email protected]> wrote: > Fossil says the artifact list is supposed to be append-only, but it also > has clusters as artifacts that are discardable. This is conceptually > suboptimal. >
Very briefly, as my elbow infection is killing my left hand, but your mail is just too good to not respond to... For someone who just started with fossil yesterday, you've come a loooong way in understanding it! > Fossil tries to keep the storage of content a separate matter from the > content itself, but doesn't fully succeed. Yes and no. It uses sqlite (the storage) to do a lot of the work, but the manifests contain all the raw metadata needed _except_ for the mapping of UUID to blob content (which is what the blob table does). > The manifest is an essential part of the content, since it contains > filenames, which are themselves content. However, some manifests also > contain a B-card for delta compression, which is a storage matter. > _Delta_ compression is a syntax extension for manifests only, and have no effect on the system outside of how their manifests are produced/parsed, so i would say B-cards are very much part of the metadata. _Content_ compression is indeed a storage issue, and is not mentioned anywhere in the manifests. The R-card looks redundant. What's it for? Very short answer: largely historical to prove data fidelity. It has in the mean time been made optional, but fossil still calculates it by default (and it's a very expensive calculation). > The Z-card looks redundant. The name of an artifact is a hash of it and > stored with it as uuid in the blob table, so you already have a way to > verify it. > "blob table" ==> storage unit. The manifest uses the UUID of the blob, but where it's stored is an implementation detail. > Do R- and Z-cards need to be cryptographically secure? No. > If so, why not use something better than md5? If not, then why not use > something much faster than md5? > Can't say - historical decision predating me. > Tags for artifacts should be properties with value «true», not with value > «nil». If the value is «nil», that should mean the artifact _doesn't_ have > the specified property, which is how Emacs does it. I.e. ⌜(put > 'some-artifact 'some-property nil)⌝ really doesn't look like it means ‟put > a property on the artifact”; it looks like it means ‟remove (nullify) the > property from the artifact”. Instead, ⌜(put 'some-artifact 'some-property > t)⌝ puts a property on. > As much as i love emacs, semantic compatibility with emacs has never been a goal. In the context of fossil, having a tag set does not imply true/false/nil - its interpretation is tag/context-specific. Most tags don't use values, and some reserved tags expect them to contain specific things (e.g. 'bgcolor' expects an HTML-style #RGB value). > Does Fossil give any warning if you receive a new ticket update with a > timestamp preceding an update that you yourself created and with a > conflicting J-card? Then #2 would notice #1's update, even though nobody > else would. This won't help if #2 dies too, but it's better than nothing. > AFAIK, no. Timestamps are inherently unreliable, as anyone can set their system clock (and many people/systems manage not to, possibly via no fault of their own e.g. a misconfigured LAN time server). -- ----- 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
