Neil Gower <neilg@digitalextremes.com> writes:
> 1. Are there any critical fixes in 1.0.5? (Security is not a big
> concern, this is for intranet use).
Nope, it was only a security fix.
(See the CHANGES file for details.)
> Also, we recently hit the 2GB strings-file limit, which breaks the
> hotcopy functionality (as per #1819). From what I can see in the list
> archives, the workaround are:
>
> a) svnadmin dump (really slow)
> b) lock out all of your users, cross your fingers, and copy the
> repository manually.
>
> Which raises my second question:
>
> 2. What is the best (current) practice for backing up large repositories?
I think hotcopy is still the most convenient way, if you recompile APR
as described in issue #1819.
If you can afford to invest a little bit of time (3-5 hours), you
might want to look at contrib/server-side/backup-recipe.sh in the
Subversion tree. That's a sample shell script demonstrating a
backup/restore mechanism. You'd have to write "real" scripts based on
the code in there, but the examples are extensively commented.
(If you do this, and your scripts are general enough, please post them
to the dev@ list, by the way.)
> And finally, a related question to the above:
>
> 3. Does the 2GB file limit affect any other areas of svn?
>
> I ask because clients have suddenly started timing out on one of our
> (large) repositories, using http:// or file://. Maybe it's something
> else, but I thought I'd check before I start worrying about drive
> failures and such.
I don't know. If they up their 'http-timeout' parameters in their
~/.subversion/servers files, does the problem go away?
Oh wait, you said this is happening even with file:// ??? How can
there even be a "timeout" error with file:// access, hmmm...
What are the exact errors people are seeing?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 14 17:44:57 2004