Stefan Fuhrmann <[email protected]> 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
