I'm investigating setting up a replacement SVN server (Apache mod_dav_svn), but would ideally like to store the actual repositories on a remote Samba share.

Edit: to clarify, client access will still go through the Apache front end, NOT directly to the repository.

Are there any reasons why this would be a (really) bad idea?

My main concern is data integrity (i.e. from files being sent to the Apache server, and then written from that server to the remote storage - especially if any packets get lost), though should the SVN itself guarantee the integrity of data before allowing each actual commit to complete?

One risk identified is that if the network or remote storage goes down, we loose access to the repo, but the network in question has built in resilience, and the remote storage is a SAN (again with resilience) so I'm comfortable with this.

Is there anything else I'm missing?


Some fast offhand reasons why this is The Terrible Bad Idea (tm) and road to Hell:

  • direct access to repositories of NFS|Winshare (without backend SVN-specific network layer) with file:/// protocol is guaranteed broken repository (it's experience, not law) sooner or later, but rather fast anyway
  • With file:/// protocol you'll lost all possibilities of authorization / authentication (and it's just inappropriate in multideveloper environment)

If you want to exclude heavyweight Apache, you still have (must???) to consider usage of another servers. It can be pure SVN (svnserver), of SVN over SSH

  • I'm not planning on directly accessing the repo with the file protocol. As I said in my original post, I'm planning on having Apache (with mod_dav_svn) as the front end. – jonny Aug 24 '16 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.