Greg Hudson <ghudson@MIT.EDU> writes:
> I think the hotcopy race is probably more of a theoretical issue than a
> practical one, unless you have a very high rate of commits (and in that
> case, maybe you have the resources to learn about turning off logfile
> removal and only remove logfiles at such a time as you're not doing a
> hotcopy). Especially since in 1.1, read-only operations don't frob the
> database so much.
It may be theoretical for most uses of Subversion, but note at least
that Mike and I have been able to stimulate the problem fairly easily.
In fact, if you apply this patch
Index: contrib/server-side/backup-recipe.sh
===================================================================
--- contrib/server-side/backup-recipe.sh (revision 10025)
+++ contrib/server-side/backup-recipe.sh (working copy)
@@ -78,7 +78,7 @@
cd ${SANDBOX}
-${SVNADMIN} create --bdb-log-keep ${REPOS}
+${SVNADMIN} create ${REPOS}
${SVN} co file://${SANDBOX}/${REPOS} wc
cd wc
to contrib/server-side/backup-recipe.sh, that script can demonstrate
the problem.
A high rate of commits makes it more likely things will go wrong; a
low rate merely makes it less likely, but not impossible.
I'm very glad for this thread. The point that backup tools are always
backend-specific makes me think we don't need an 'svnadmin dump'
solution. Rather, something based on today's hotcopy might work fine,
as long as we doc its limitation carefully, make it warn if logfile
autoremoval is turned on, and it does its best to detect problems when
the backup actually happens.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 18 18:06:01 2004