[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1331883 - /subversion/trunk/subversion/svnadmin/main.c

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 16 Oct 2012 10:07:33 +0200

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

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.

Received on 2012-10-16 10:08:39 CEST

This is an archived mail posted to the Subversion Dev mailing list.