Menu
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.
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
535
You can either store your repositories locally and access them using the file:// protocol or you can place them on a server and access them with the http:// or svn:// protocols. The two server protocols can also be encrypted. You use https:// or svn+ssh:// , or you can use svn:// with SASL.
TortoiseSVN is an Apache™ Subversion (SVN)® client, implemented as a Windows shell extension. It's intuitive and easy to use, since it doesn't require the Subversion command line client to run. And it is free to use, even in a commercial environment. Simply the coolest Interface to (Sub)Version Control! read more...
SVN stands for Subversion. So, SVN and Subversion are the same. SVN is used to manage and track changes to code and assets across projects.
Depending on which requirements you have (I don't think that your list is complete), it may be sufficient to use TortoiseSVN only. I am the only user of the Subversion repository. All of the users have access to the server. You don't want to have access rules that restrict access to parts of the repository.
All of the users have access to the server. You don't want to have access rules that restrict access to parts of the repository. Create a new subversion repository on the server by using the command "Create Repository Here".
The repository is a storage location on disk where all the versioned data is stored. You can store the repository on your local machine or a remote server where users can access it either through the Subversion Daemon service or through HTTP via an Apache module (separate install).
Rather Subversion manages changes by merging source files with any changes made and only notifies you of conflicts if there are changes that cannot be merged (i.e., changes to the same line of code typically). Coming from a background of using integrated security in Visual Studio, I at first had my doubts about the merge approach.
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.
179
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
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
