views:

1211

answers:

4

Hi all,

There are currently 5 developers on my team and we all access a repository through a shared drive on computer X which is on our network. Since we all have access to computer X, and we can manage who has and who doesn't have access to computer X, we can manage who can access our repository.

My question is this: If I set up a subversion server, do I gain any functionality that I don't already have? The repositories already have user/passwd control built right in.

Do I gain the ability to track who currently has a file checked out? Do I gain the ability to give a lock to more than one person (Only users a and b have a file locked, no other users can check out that file)? Do I gain any security? It seems like I don't, because, again, I already have user/group/passwd control without a server.

Please let me know. I'm deciding whether or not there's any advantage creating a server.

Thanks, jbu

+1  A: 

Generally, you don't "check out" files in SVN. That is, you don't lock them while working on them.

You gain several things however, (these are just from the top of my head):

  • Commit history (both per file, and for the repository as whole)
  • Branch/Merge options
  • The ability to tag versions (often formal releases)
  • The ability to rollback changes to a certain revision (e.g., if a serious bug was recently introduced)
  • and many many more

Note however, that most or all of these benefits are not unique to subversion, but can be gained from most of the modern version control systems.

Einar
actually we get all of this functionality without a subversion server. We already have subversion repositories - just no server.
jbu
Ahh sorry, I misunderstood. I read it as you were just reading/writing files of a shared drive.
Einar
Forgot to add: perhaps you should edit your original question to make this a bit more clear (I saw another SO user wasn't sure about this either).
Einar
+1  A: 

Yes, you could do several additional things:

  • Additional authentication mechanisms (Basic-Auth over HTTP/S, ssh shared key auth)
  • Using Apache+mod_dav_svn you can configure finer grained access control, on a path by path basis

edit: Unsure if you're using subversion currently over a file-share, or only using a plain file share. (SVN can use file:/// URIs as well).

Mark Renouf
yes, we are currently using a subversion repository. Sorry for not mentioning that.
jbu
+18  A: 

Yes, you would gain a lot: you reduce the risk of loosing all your data!

See the docs (and warnings) about accessing a repository on a network share.

Stefan
I regret that I only have one upvote to give for this warning.
David Thornley
+2  A: 

When you access the repository through a file:/// URL, the subversion libraries will assume the repository is available on a local disk and will not attempt (or even be able) to minimize network I/O. Accessing the repository through a svn:/// URL is therefore much faster for certain operations where a lot of data needs to be read just to determine the fraction that needs to be send to the client, as is the case for the svn switch command.

I don't dare say the same about http:// access. The http protocol is relatively chatty and inefficient in svn 1.5. There are plans to improve this for svn 1.7

Wim Coenen