[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: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 15 Oct 2012 22:47:40 +0100

Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:

> On Mon, Oct 15, 2012 at 7:36 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>wrote:
>
>> (It also has the pretty odd side effect that it's not safe to run
>> 'svnadmin1.7 setrevprop' and 'svnadmin1.8 dump' concurrently on the
>> same repository...)
>>
>
> That's a misrepresentation of what is going on.
>
> Running svnadmin setrevprop and svnadmin dump
> concurrently, has never had a well-defined behavior.
> I.e. the propset may or may not have shown up in
> the dump (basically a race condition).

That's a bug in 1.7. When the r1237779 backport is approved 1.7 will be
using the atomic revprop mechanism for load, and since it already uses
the atomic mechanism for setrevprop any race will be detected and the
second operation will fail.

> The same
> thing is true for 1.8 and any combination of 1.8 and
> older tools.

1.8 before revprop caching would use the atomic revprop change mechanism
to detect the race and return an error.

There is still a bug in 1.7/1.8 here, we should stop using
svn_repos_fs_change_rev_prop2 in load-fs-vtable.c:change_rev_prop and
use a function that bypasses validation but still uses the atomic
mechanism. No such function currently exists :-(

-- 
Join us this October at Subversion Live 2012
http://www.wandisco.com/svn-live-2012
Received on 2012-10-15 23:48:16 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.