Re: Revprop caching 'n stuff

Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de> writes:

> * undo the above-mentioned revs on /trunk

Good. I was starting to have concerns about other races in the current
code. For example:

  - first process reads generation file N
  - second process writes new revprops
  - first process reads revprops
  - second process writes generation file N+1

This means the cache doesn't have revprops for N but for some n>=N. I
suppose the system might work with this sort of cache but I'm not sure
it has been considered. I suppose the reader could loop, rereading the
generation file after reading the revprops file until it sees the same
generation before and after revprops.

Another example:

  - first process reads/caches revprops for generation N
  - second process writes new revprops and gets killed before updating
    the generation file
  - third process reads/caches revprops and gets new revprops plus
    generation N

This means two readers that have different revprops for generation N.
Both of them will believe they have up-to-date values if they reread the
generation file.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com