Julian Foad <julianfoad_at_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*
Received on 2014-01-23 11:55:47 CET