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
Received on Fri May 6 15:10:59 2005