On Tue, Oct 16, 2012 at 7:13 AM, Stefan Fuhrmann
<stefan.fuhrmann_at_wandisco.com> wrote:
> On Tue, Oct 16, 2012 at 5:51 AM, Branko Čibej <brane_at_wandisco.com> wrote:
>>
>> On 15.10.2012 17:14, Stefan Fuhrmann wrote:
>> > However, if you have a long-running process like a server, that race
>> > condition extends now extends over its whole lifetime. I.e. once a
>> > revprop got read, any change to its value by a pre-1.8 tool may never
>> > get detected.
>>
>> Ouch. This seems wrong. I'd understand a design like this if the
>> long-running server were the only process accessing the repository, but
>> that has never been the case in Subversion. In this case, a cache that
>> can't detect out-of-band changes to the canonical dataset isn't very
>> useful.
>
>
> *sigh* If you really have to use 1.7 tools on an 1.8 server,
> you can't use revprop caching. Most people, however,
> will use 1.8 svnadmin on 1.8 servers.
That seems okay to me. If you use all 1.8(+) tools, then out-of-band
changes will be detected. I haven't done any measurements, but I
expect the performance advantages of revprop caching to be quite
significant.
Mixing tool versions will be done by say 0.1% of svn admins. I think
it would be a pity to deprive every sane svn administrator of this
performance advantage because of this edge case. As long as this
limitation is documented in the release notes, I'm okay with it.
--
Johan
Received on 2012-10-16 10:08:39 CEST