On Mon, Oct 15, 2012 at 7:36 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>wrote:
> Stefan Fuhrmann wrote on Mon, Oct 15, 2012 at 19:32:57 +0200:
> > On Mon, Oct 15, 2012 at 7:10 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name
> > > Daniel Shahaf wrote on Sun, Apr 29, 2012 at 12:58:56 +0300:
> > > > stefan2_at_apache.org wrote on Sun, Apr 29, 2012 at 09:12:49 -0000:
> > > > > Author: stefan2
> > > > > Date: Sun Apr 29 09:12:48 2012
> > > > > New Revision: 1331883
> > > > >
> > > > > URL: http://svn.apache.org/viewvc?rev=1331883&view=rev
> > > > > Log:
> > > > > SvnAdmin should always have revprop caching enabled such that
> > > > > the infrastructure is being set up to notify *other* processes of
> > > > > changes done by e.g. setrevprop.
> > > > >
> > >
> > > What happens if 'svnadmin1.7 setrevprop' is run while a 1.8 server is
> > > running? Will the 1.8 server miss svnadmin1.7's changes because the
> > > latter doesn't have revprop caching enabled?
> > >
> > Yes. To use revprop caching, all applications
> > accessing the same repository must be 1.8+.
> This does not seem to be documented.
Will update the release notes.
> (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). The same
thing is true for 1.8 and any combination of 1.8 and
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
Join us this October at Subversion Live
for two days of best practice SVN training, networking, live demos,
committer meet and greet, and more! Space is limited, so get signed up
Received on 2012-10-15 23:14:37 CEST