On 31.03.2012 23:30, Ashod Nakashian wrote: >>> Git can keep deleted items until git-gc is invoked, should we support >> something similar, we need to be consistent and probably support arbitrary >> revision history, which is out of scope. >> >> I'm confused: how does revision history affect the pristine store? > If the pristine store also keeps multiple revisions, then it's a whole > different set of features than what we are aiming for (at least for > compressed pristines).
Certainly the pristine store keeps multiple revisions of files. After all, it's just a SHA-1 => contents dictionary, so every time you "svn update," you'll get new revisions of files in the pristine store. What the store doesn't do is /know/ about the revisions. Neither does the wc.db, which only tracks reference counts for the SHA-1 keys. Every time a file changes, its hash will change, too, a new key will be inserted in the pristine store, and the reference count for the old key will be decremented. I'm not sure what happens when the count reaches zero; used to be that only "svn cleanup" would delete unreferenced pristines, but ISTR this changed a while ago. In any case, the pristine store shouldn't worry about revisions, only about efficiently storing the contents. It doesn't even have to worry about reference counting, since wc.db already does that. -- Brane P.S.: If we ever implement local snapshots and/or local branches, it /still/ won't be the pristine store's problem to track whole-tree info. This is why I like the clear separation between pristine store, which is a simple dictionary, and wc.db, which is moderately complex. P.P.S.: When we transition from pristine store per working copy to pristine store per ~/.subversion directory, then the pristine store will have to track how many working copies are using it. But that's way in the future -- and another good reason to use a proper database for the indexing.
