Subversion server and NAS (AKA "NAS Enemy Unknown")

[robin]

Don't really know where to ask so I'm asking there, since I know there are some skilled programmers around.

I'm on an impossible quest to setup a SVN server at my workplace.
The server would be just a regular pc with ubuntu linux as OS, that uses apache (httpd) to serve subversion.
I followed this tutorial using a virtual machine as server, and everything works; so hopefully I should be able to replicate the process on the physical machine.
Now my problem is that the repos should be stored on a NAS drive that is connected (LAN) to the physical server, instead of being stored directly on the machine internal HDD.
So in my naivete I'm thinking I just need to change this

Code: [Select]

<Location /svn>
#...
SVNParentPath /mylocalfolder/svn
</Location>to this

Code: [Select]

<Location /svn>
#...
SVNParentPath \\myNAS\svn
</Location>But I strongly suspect it won't work and I can't test this condition using the virtual machine.

Anyone know if this is as foolish as I suspect or not?
I tried some google-fu but most people out there seem to want to setup the server directly on the NAS drive, while I want to use a proper machine as a server, just telling it to store the stuff on the network HDD.

Thanks.

[R1dO]

First thought.

Can't you just mount the NAS path first (for example under /mnt/myNAS ) and then refer to this path under svn?
Of course the details for the mounting operation depend on the way the the NAS drive is accessible (NFS, samba, some other network magic), but at least you let the OS deal with user authentication.

Another thought
What are your motives for requiring a separate server setup. If you are too unfamiliar with the subject the most likely outcome is that you are setting things up for multiple points of failure, instead of just one.

Hope this is of any help,

[robin]

Thanks for the answer!
I'm obviously too unfamiliar with the subject

About the separate server setup:
I read that the proper way to setup svn for a team, is to setup an apache server that serves svn; conversely the "internal" svn server should only be used for testing purposes.
I also read that directly putting a shared repository on a nas is wrong, because the server manages the access to the repo and stops multiple people accessing it at the very same time, making it corrupt.

[R1dO]

Don't worry,

My familiarity never went beyond squaddy level. And it has been on the decline since i decided to switch to git for everything that could use a repository.

I'm not sure where you've read the "proper way" but i think that info is a bit one-dimensional. There are alternative ways (for instance svnserve deamon).

Furthermore stating repository corruption due to a server managing the repo and user authentication comes across as spreading bogus information.
Once a server handles authentication it is normally not possible to corrupt the main repository (the server should guards against concurrent edits). The most common way corruption can occur is when you allow users to communicate with the repository using direct file-system access (for instance a samba or nfs shared folder).

Perhaps it is better to consult  the documentation from the developers which is a lot more helpful than a simplified tutorial, especially for your advanced setup.
I can recommend chapter 6

Good luck

[robin]

I could actually use git (or Mercurial) instead of Subversion, I don't specifically need the latter.
I went for svn because the workflow seemed more straightforward, thus more appropriate for what we're doing (we don't do programming).
Do you think that git is more simple to setup than svn, for a team on a local-network?
I already use git personally at home, but I guess the setup for a team is wildly different.

[R1dO]

Since git (and mecurial) are distributed by nature I think they will almost always be easier to setup and administer for teams (location does not matter for that "bold" statement). Unless your coworkers are already highly skilled in svn.

The thing that worries me though is your statement on being "more appropriate ... dont do programming". In my mind it translated to ... i want to store versioned binary blobs (e.g. images, sounds and videos) which are changed quite frequently. If that is the case i would advice against ANY version control system designed for code (svn, git , mercurial , bazaar, etc), since those do not scale nice when it comes to huge amounts of data.

Besides this i have a hard time envisioning why setting up an advanced svn server (or git for that matter) on a NAS is so important for your employer (assumed by your workplace reference). Especially when there are enough online repository storage services available for relatively low prices (github, bitbucket, gitlab, Visual Studio team-services, etc). Most of them include extra services for teams (for instance: wiki-pages for docs, issue-trackers/planners).

Perhaps you can share what you want to achieve (e.g. the why ... not how) with your desired setup?

[robin]

Yes, we're going to store binary files (images), but these files are not changed frequently: usually no more than twice (first a draft, then the final version) and just occasionally trice, if there is some mistake to fix. We also have xml files which on the contrary are changed a lot of times.
I know those tools are designed for code but I think it could be ok, given the fact that images are changed only a few times.

I looked a bit into git and I came across a setup for a local network, that uses ssh keys to connect to the central shared repo. It seems more simple than setting up apache, and the result would be sufficient for our needs. I also need to look into Gitolite which seems to be able to achieve a similar (if not the same) result.

I actually like dealing with this stuff, that's why I'm trying to do it myself, the problem is that I'm really a total noob.