You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "D.J. Heap" <dj...@shadyvale.net> on 2005/05/06 13:10:04 UTC

Re: svnadmin hotcopy fails

I think there are more problems with hotcopy than I initially thought...

For bdb repositories (subversion/libsvn_fs_base/fs.c:base_hotcopy), the 
db/format file is never copied and the locks tables is always copied -- I 
don't think that table will exist if the repo hasn't yet been upgraded, will 
it?  Or does hotcopy itself cause an upgrade on bdb repositories?

For fsfs repositories (subversion/libsvn_fs_fs/fs_fs.c:svn_fs_fs__hotcopy), 
the db/format file is always copied which causes a failure on old 
repositories, and the locks table is never copied which doesn't seem ideal 
(or is it intentional that locks are not copied?)

Is my understanding correct?

I'm also unsure what it means for a repo to be db/format version 1...it 
seems to just indicate the underlying fs format and doesn't say anything 
about whether or not a locks table is present?

And lastly, is hotcopy still safe to use if locks are being added/dropped 
simultaneously?  Presumably it is with bdb since the locks table is safely 
copied the same way the other tables are.  But it looks like fsfs just grabs 
'current revision' and uses that to safely copy committed revisions -- I 
guess the repositories 'write_lock' will be needed to safely copy the locks 
table?

DJ


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org