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

Re: flushing caches upon repository replacement - was: Copy and Reduce the size of SVn repos

From: Ben Reser <ben_at_reser.org>
Date: Mon, 09 Mar 2015 16:22:28 -0700

On 3/9/15 3:12 PM, Ivan Zhakov wrote:
> On 9 March 2015 at 23:31, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> Andreas Stieger wrote on Sun, Mar 08, 2015 at 17:52:55 +0100:
>>> On 08/03/15 17:45, Branko ─îibej wrote:
>>>> And it bears repeating: If you replace a repository, please make sure to
>>>> restart Apache and/or svnserve to clear stale caches.
>>> Is there something that can be done in the code to take care of that?
>>> Like watching the inode as {uuid,inode}-2-tuple and flush the caches if
>>> it changes?
> This problem already has been fixed in r1618138 [1]
> [1] http://svn.apache.org/r1618138

The reason Branko said you need to restart the server after replacing the
repository isn't fixed in a released version (nor will it be fixed in 1.9).
1.9 does fix collisions between two repositories in different paths that have
the same UUID. The original commit (that you linked in your post) tried to
solve both but we ultimately reverted the instance ids being in the cache keys
because the problem is ultimately impossible to fully fix given our
architecture (there's a note from the future on the commit message you mention
pointing to the discussion about this and ultimately why this was reverted).

But the short version is that even inserting the instance ids into the cache
only decreases the window that the resulting problem from not doing what Branko
suggests (restarting the server after replacing a repository). Most of what we
end up fixing is the warning signs that help educate users that they shouldn't
be doing this. I.E. we eliminate errors in non-destructive cases and leave the
potentially destructive cases that are less likely to happen.
Received on 2015-03-10 00:23:01 CET

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