SVN without server for our Visual Studio development

Security is not an issue for our small team. Is there any compelling reason why we might need to use an SVN server of some sort, rathe开发者_如何转开发r than just using files on a network share somewhere?

EDIT

Sorry--I don't think I communicated very well.

I want to use SVN for version control. I think that I do not need a "server". The team members can all point their SVN clients to a network location.

Is that good enough?

Or do I need a "server"?

Yes, you can create a repository on some folder and point your clients there, no svnserve process or apache2 + mod_svn is really needed.

There are a however a couple of reasons why you should consider a server:

• Synchronicity: A file based repository is altered by the clients that access it. If one of your clients' clock is out of sync with the rest of the team, he/she may in rare cases corrupt the repository data. A server however will always have a unique time.
• Scalability: When the amount of commits per day grows, the file based lock/commit/unlock sequence may cause unexpected load on the file server and frustrate your team with long response times.
• Extensibility: Better sooner than later you or your team will discover the need for a ticket system (for QA/QC or 3rd level support, e.g. Trac, Redmine, Bugzilla) and then having issues and their fixes associated with revision control will indeed become a must have. These ticket systems always accept a svn:// URL but will most likely reject a file based repository.

I don't know if these reasons are compelling enough for you, but you can indeed postpone the decision to go server until it starts to become unavoidable - even indefinitely if your team does never grow.

Agent SVN is a Subversion plug-in for Visual Studio and it can be configured to use a file location for the repository and as such no server is required.

The main purpose of svn is for version control. Using files is not easy to keep versioning. And btw, you may setup the "svn server" local in your own pc

Subversion uses three main protocols:

• svn:
• http:
• file:

There are a few others (svn+ssh and https), but they're related to the above.

If you use the file: protocol, you don't need a Subversion server. All you have to do is point the file protocol to the directory where your Subversion repository lives:

C> svnadmin create C:\svnrepos\myrepos

C> cd C:\workspace
C> svn co file://C:/svnrepos/myrepos repos

In the above, I created a Subversion repository in C:\svnrepos\myrepos and then went to another directory (very important!) and did a checkout. No server is running.

There are several issues with this:

• The Subversion repository directory must be read/write accessible to everyone which means that anyone can directly modify the repository without going through Subversion.
• I'm not 100% sure how hooks work or how collisions are handled if more than one user attempts to commit at the same time.
• Even if you don't plan to have any security, you probably want to know the name of the person who made the change. The file:// protocol doesn't track that. All you see is that changes were made, but not by whom.

And, finally:

• Running a server isn't all that difficult.

So, although you could put the Subversion repository on a network share and everyone can use the file:// protocol, there really isn't a very good reason to do that. In fact, I use Subversion as my own personal repository where I'm the only one using it, and I don't use the file:// protocol.

You can easily run svnserve as a Windows service, so it automatically starts whenever your machine starts up. And, it's very simple to setup. There's simply no reason not to use it.

So, might as well go ahead and do it the right way anyway.

By the way, how are you using Subversion through Visual-Studio? I suggest you look at ankhsvn which allows you to access Subversion directly in Visual-Studio.

SVN isn't about security; it's about maintaining history of your source code.

I can't think of a compelling reason why you would not want to set up an SVN server. I use one at home on my personal desktop for my own development. It's not about security; it's about keeping my source code history in case I screw up and want to revert.

It's also about habits: "First we make our habits, then our habits make us." Learn to do it right all the time, even in simple situations.

Imagine working on the same project with multiple people. And both are modifying the same file at the same moment. If you both work on that same fileshare that is going to be bad. Another reason for using some kind of source control is being able to keep track of changes. This way you can notify your collegue where he screwed up. :-)

hmmm, subversion is not the right tool if you need security, it is the right tool :

• if you want to have a team working on the same sources at the same time (and be able to revert a bad commit)
• if you want to avoid that the last one who save a file erase all the modifications made by the other (in case of files on the same network share)
• if you need to make parallel developement (and create branches for that)
• if you need to be able to re-extract a tagged version (usefull when delivering the application)

Setting up a server is almost trivial, so I would ask why would you NOT want a server. But here are some other reasons:

1. Reliability. Network filesystems such as SMB share are not as reliable, especially when it comes to multiple users writing to the same files at the same time. SVN specifically does not claim to support this.
2. Performance. Providing access to the files via a server will be significantly faster than doing it over network share.
3. Auditing. You want your changes to be associated with a user, even if you do not care about security. Going through a server forces a login and the server can use that username to record who made the change.
4. Safety. If you use a network share, then all users have direct read/write access to the repository files. I know you are not concerned with security, but what about simple mistakes? Such as someone accidentally deleting files from the repository.

Download and install something like Subversion Edge. This is trivial to install on Windows and it gives you a web UI to manage the server. You also get a web UI for browsing repositories which can be useful when researching a bug.

On a team of as little as two people, some sort of version control is a huge advantage over no version control. Being able to back-track through changes, branch code if you need multiple versions for demoing purposes, and using lock/unlock + merge to keep developers from murdering each others code is why you use SVN. Comes in handy when working alone on a project, too.

You can host SVN easily on Linux, Mac, Windows - you just need that machine to be network-connectable from the development machines.

You need an SVN server process running somewhere. You cannot avoid it. It is a fundamental part of SVN, it is what provides access to your repository, and it is what the clients must point to.

We use VisualSVN. It takes almost no effort to install.