Clark Sell

I setup a small repo with SVN and was in awe. I don’t think I spent more that 30 minutes starting from scratch to committing files. I used it for a few months and decided I better move the DB to a RAID I had sitting on another sever. This would give me the reliability of a raid yet run SVN on a separate machine.

WRONG!! I was able to mount a directory to a share on another server with the RAID. svnadmin created the DB just fine, but things puked when I tried to use it.

It logged the following:

(20014)Error string not specified yet: Berkeley DB error while opening environment for filesystem /PATH/To/Repos/ db:\nInvalid argument

[error] [client XXX.XXX.XXX.XXX] Could not fetch resource information. [500, #0]

[error] [client XXX.XXX.XXX.XXX] Could not open the requested SVN filesystem [500, #160029]

[error] [client XXX.XXX.XXX.XXX] Could not open the requested SVN filesystem [500, #160029]

I hit the SVN book to see what I had done wrong only to find this.

Warning

Do not create your repository on a network share—it cannot exist on a remote filesystem such
as NFS, AFS, or Windows SMB. Berkeley DB requires that the underlying filesystem implement
strict POSIX locking semantics, and more importantly, the ability to map files directly
into process memory. Almost no network filesystems provide these features. If you attempt to
use Berkeley DB on a network share, the results are unpredictable—you may see mysterious
errors right away, or it may be months before you discover that your repository database is subtly
corrupted.

As stated on page 83 of Version Control with Subversion

and so the boat sailed off into the distance with all the n-tier SCC users as SVN stood there watching.

BUT there is good news…..

The SVN team stated as a long term product goal they were going to add a SQL repository back-end. You can stay informed about it here.