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.
Fossil tries to keep the storage of content a separate matter from the content itself, but doesn't fully succeed. 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. The R-card looks redundant. What's it for? Whatever would use it for verification could just use a hash of the manifest itself instead (and verify the individual F-card hashes in addition to the hash of the manifest). Or if the goal is to have an identifier «I» that's a function just of the files (and their names) that doesn't depend on any of the other data in the manifest, then what's the point in putting the F-cards directly in the manifest, rather than putting them in a separate artifact and putting the hash (i.e. «I») of that artifact in the manifest, like Git does? 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. Do R- and Z-cards need to be cryptographically secure? If so, why not use something better than md5? If not, then why not use something much faster than md5? Fossil records renames, on the theory that file identity matters, unlike Git does. If I rename two files to each other, then swap their contents, then commit, then Fossil records exactly what happened, whereas Git thinks nothing happened. Also if I delete a file, commit, then create a new file with the same name, and commit, Fossil (and Git) records this. However, it appears that if I delete a file, then create a new file with the same name, _without_ an intervening commit, then Fossil would be as oblivious as Git is; the manifest has no way to record what happened (it would record it just as a change of content for the file). This is a defect, if file identity matters. 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. Consider the following sequence of events: A drive-by reader submits a bug report. ‟Hi, I just looked at your code. Maybe there's an overflow on line #xx?” Developers #1 and #2 synchronize to the server, and get the new report. #1 changes the bug status to security-critical, and he's right. #1 immediately re-synchronizes so the other developers will know. #1 then dies. #2 changes the bug status to not-a-bug, saying ‟Line #yy obviously prevents overflow”, but he's mistaken. #2 re-synchronizes so the other developers won't be bothered by yet another bogus bug report. Everybody else synchronizes later. Nobody, not even #2, ever notices #1's update (even though everybody receives it), because #2's silently overrides it. 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. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
