----- Original Message ----- > From: Branko Čibej <br...@apache.org> > To: Ashod Nakashian <ashodnakash...@yahoo.com> > Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> > Sent: Sunday, April 1, 2012 12:23 PM > Subject: Re: Compressed Pristines (Summary) > > 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.
Sure. I meant multiple revisions of the same file. You're absolutely right, the PS tracks SHA-1 and whether two files are revisions of the /same/ file or not isn't relevant. What I meant to say is that if we are to have such a case, we probably need to add support for it on the higher level where files/revisions/SHA-1's/references are tracked. This is out of scope and changes the very definition of the PS as we have it now. > > 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. > Sure. We're on the same page here on all points. -Ash
