6

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.

  1. Do I gain the ability to track who currently has a file checked out?
  2. 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)?
  3. 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

TheTechGuy
  • 16,560
  • 16
  • 115
  • 136
jbu
  • 15,831
  • 29
  • 82
  • 105
  • EDIT: our current repositories on this shared drive on our network is ALREADY a subversion repository. – jbu Jan 30 '09 at 16:00

4 Answers4

22

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

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

xpda
  • 15,585
  • 8
  • 51
  • 82
Stefan
  • 43,293
  • 10
  • 75
  • 117
2

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
  • 66,094
  • 13
  • 157
  • 251
1

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
  • 3,279
  • 2
  • 26
  • 28
  • actually we get all of this functionality without a subversion server. We already have subversion repositories - just no server. – jbu Jan 30 '09 at 15:59
  • Ahh sorry, I misunderstood. I read it as you were just reading/writing files of a shared drive. – Einar Feb 02 '09 at 08:03
  • 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 Feb 02 '09 at 08:05
1

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
  • 30,697
  • 19
  • 94
  • 123
  • yes, we are currently using a subversion repository. Sorry for not mentioning that. – jbu Jan 30 '09 at 16:00