Julian Foad <julianf...@btopenworld.com> writes: > I get the problem. By "store its own 'head' revision" I meant store > the maximum value of any referenced revision number -- in other words, > simply a substitute for having an index and querying the maximum value > in the index. If we update this value correctly then it would serve > the same purpose as an index (but maybe faster or maybe not). Like > this: > > Before adding the rep cache entries for a (recently) committed revision rX: > > if (max_referenced_rev >= X): > raise error > # caller should escalate the error or clean up the rep-cache > max_referenced_rev = X > > Before/during looking up a rep cache entry, when repository head is rY: > > if (max_referenced_rev >= Y): > raise error > # caller should escalate the error or clean up the rep-cache > > In a roll-back to revision Z: > > delete where rep_cache.revision > Z > max_referenced_rev = Z > > I suppose the risk involved in users failing to do the roll-back > correctly (in this case, failing to update max_referenced_rev) would > still be present which perhaps makes the index approach superior.
That might work but how do we stop old code updating the cache and failing to update max_referenced_rev? We don't have any version number in the rep-cache schema so that is going to be ugly. Bump the FS format? Rename the rep_cache table? With the index we could have the new code create any missing index when opening the rep-cache, there would be a one-time delay the first time new code was used on a big cache. Old code would update the index but not do the validation check. The validation check done by the new code would include any rows added by old code. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
