Source control system for single developer

Question

What\'s the recommended source control system for a very small team (one developer)?

Price does not matter. Customer would pay :-)
I\'m working on Vista32 with V

Answer 1

I use Springloops - version control tool for developers

1. SVN / Git version control
2. Automatic deployment to servers
3. Create repositories
4. Invite people
5. Import files
6. Great support

So, try Springloops

Answer 2

I dont see why the fact that your one developer changes anything on the source control issue. I would follow the same system (in fact I do on my solo projects). I use wush.net (svn and trac) in those cases. It's fast to set up and dont require that you yourself do or know any server issues. I recommend you use something like this.

Answer 3

I realize that cost isn't a problem but a nice free solution that wouldn't involve checking in and out would be to host the code within Dropbox by doing this you'd instantly get versioning and backup which are the main features that a single developer system would provide.

Answer 4

I would use Subversion (in fact I use it) [update: Jul 2014 -- I use Git -- see end of the answer]. SVN is:

• free,
• good enough (see disadvantages below),
• simple,
• works fine on Windows (and Linux too),
• a lot of people use it so it's easy to get help,
• can integrate with most of IDEs i.e. Visual Studio (i.e. ankhsvn or VisualSVN -- more info) or Eclipse (i.e. Subclipse -- here someone asked about that).

I would strongly recommended separate machine to source control server. At best somewhere on the cloud. Advantages:

• You don't lost your source control repositories if your development box dies.
• You don't have to worry about maintenance of one more box.

There are companies which host SVN repositories.

Here are links to SVN (client and server) packages for various operating systems.

Disadvantages of SVN

I am using SVN on Windows machine for about 5 years and found that SVN has a few disadvantages :).

It is slow on large repositories

SVN (or its client -- TortoiseSVN) has one big disadvantage -- it terrible slow (while updating or committing) on large (thousands of files) repositories unless you have SSD drive.

Merging can be difficult

Many people complain about how hard merging is with SVN.

I do merging for about 4 years (including about 2 years in CVS -- that was terrible, but doable) and about 2 years with SVN.

And personally I don't find it hard -- on the other hand -- any merge is easy after merging branches in CVS :).

I do merge of large repository (two repositories in fact) once a week and rarely I have conflicts which are hard to solve (most of conflicts are solved automatically with diff software which I use).

However in case of project of a few developers merging should not be problem at all if you keep a few simple rules:

• merge changes often,
• avoid active development in various branches simultaneously.

Added in July 2011

Many devs recommended Distributed Version Control like Git or Mercurial.

From single developer perspective there are only a few important advantages of DVCS over SVN:

• DVCS can be faster.
• You can commit to local repository without access to central one.
• DVCS is hot thing and fancy to use/learn (if someone pay for your learning).

And I don't think merging is a problem in case of single developer.

Joel Spolsky wrote tutorial about Mercurial which is definitively worth to read.

So, despite of many advantages of DVCS I would stay with SVN if merging or speed is not a problem.

Or try Mercurial, which according to this and this SO questions, is better supported (in July 2011) on Windows.

Added in July 2014

For about a year I use Git (Git Bash mainly) for my pet-projects (i.e. solving Euler problems) and local branches for each Euler problem are really nice feature -- exactly as it is described as advantage of DVCS.

Today Git tooling on Windows is much, much better then 2 or more years ago. You can use remote repo (like GitHub or ProjectLocker and many others) to keep copy of your project away from your workstation with no extra effort/money.

However I use GUI client only to looks at diffs (and sometimes to choose files to commit), so it's better to not afraid of command line -- it's really nice.

So as of today I would go with Git.

Answer 5

I would definitely recommend git

Works great for both big and small teams. Only drawback is poor native windows support. Although it works fine for me in Cygwin. There also exists a native windows port.

Some of its benefits:

• Excellent support for a non-linear work flow. Its branching and merging is far better than eg Subversion.
• Good tools to navigate your repository
• Handles large projects well.
• It is not possible to modify the history without changing the cryptographic signature of your repository
• With its non monolithic design, it is easy to script.

Some people find that it has a steep learning curve. But once you understand it you can do almost anything you would want with it.

Answer 6

I would recommend using subversion. Many have recommended using a seperate box as a server, in case your dev machine dies. What happens when the SVN server dies? The answer here is that no matter where you choose to run the server, ensure you always do frequent backups, possibly automated daily to some secondary, preferrebly offsite machine.