Source control system for single developer
Version ControlVersion Control Problem Overview
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 VS 2008 in C++ and later in C# and with WPF. Setting up an extra (physical) server for this seems overkill to me.
Any opinions?
Version Control Solutions
Solution 1 - Version Control
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.
Solution 2 - Version Control
I would also recommend Mercurial. It's command set is much like the one found in Subversion, so the learning curve is not that steep. As mentioned earlier, it's designed to run locally, but it's also easy to share/merge changes across computers, or even just push it to a remote server for backups.
It offers excellent tools, like TortoiseHG, and it has good plugins for NetBeans and Eclipse. It also runs natively on Win32, as it's written in Python.
If you don't want to set up a server yourself (for backups, e.g.), there are free hosting providers available; there's a comprehensive list on The Mercurial Wiki.
Solution 3 - Version Control
I would definitely recommend [git][1]
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][2].
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.
[1]: http://git-scm.com/ "git" [2]: http://code.google.com/p/msysgit/downloads/list "msysGit"
Solution 4 - Version Control
Go for subversion and tortoiseSVN, you don't need to set it up on a server.
- Costs are zero
- The subversion documentation is great and fun to read
- tortoiseSVN is a very convenient client
Solution 5 - Version Control
Sourcegear's Vault is a great option, it runs on SqlServer and it has been around for many years. I would not use any version of VSS (Visual Source Safe).
Solution 6 - Version Control
Subversion has very low barrier to entry.
TortoiseSVN is a free client, and integrates into your explorer- i.e. in right mouse click menu.
The repository can be just a directory somewhere on your PC or on a network drive. Backing up just means zipping up this directory
There are a few plugins to Visual studio for Subversion, AnkSvn is one I have used, it is free and integrates nicely (i.e it will be smart about moving and deleting files etc)
Subversion is a good choice for one developer.
Update:
Since this post, I've been using Mercurial. It is a Distributed SVN. The 'distributed' aspect may not be directly useful to a sole developer, however it is better at merging and is somewhat faster. There is also a free and good Windows Explorer extension client - Tortoise Hg.
So in summary, if you are the sort of person who will work on many branches at once (doing spikes etc) or if you work on multiple PCs at once and would like full offline access to checkin history on both, then Mercurial. If you just want simple tracking and a well proven and easy to understand solution, then Subversion.
Solution 7 - Version Control
I'm surprised no one has mentioned Perforce. It's free for 2 people, blazingly fast, and integrates with VS. Also source server has bindings for it by default.
In addition to source control, it really is worthwhile to complete the loop and setup a symbol server and a source server, so that you have simple debugging of anything you've shipped (e.g. no more searching for pdbs or source that match the binary). Both source and symbol server are completely free and supported in VS since 2005.
Solution 8 - Version Control
I use Mercurial. It runs a treat running stand alone on my Vista development system with no other dependencies required. I use the command line but there's also TortoiseHG to integrate with Explorer.
Two comments:
- There are other tools which probably integrate with VS better. I think Subversion has nice VS plug ins.
- The benefit of a separate server is that it's a nice backup of all your work in case your HDD dies on you etc. so discount having one.
Edit: @Slartibartfast - if you just want to run source code control on a single machine a Distributed Source Code Control tool like git or Mercurial is ideal since they're designed to run complete repositories on a machine without the overhead of a server. The fact that you never connect your repository to anyone else's to push and pull changes doesn't mean that tool won't be right.
Solution 9 - Version Control
You can use Vault from SourceGear, the replacement tool for visual studio source safe. The IDE is integrated in Visual Studio.
The tool is free for single user.
More information: http://www.sourcegear.com/vault/index.html
Solution 10 - Version Control
There are two possible solutions for your problem: centralized VCS or Distributed VCS (DVCS).
Centralized VCS like Subversion would satisfy you feature for committing and browsing the log. It also enables you to safely store your repository to another computer which should be one of your major goals as hard drive failure is always a possibility. However, using Subversion the history still resides only at the central location making it vulnerable and you stated that you do not want to have another server.
Distributed Version Control Systems (DVCS) such as Mercurial and Git enable you to do more complex operations on your repository. With both of those tools the whole repository resides with the same computer making it bit easier to make backups and using the repository with another computer e.g. laptop. While Mercurial might seem complex at first the operations you would use with subversion are pretty much the same with Mercurial. Therefore there is no extra overhead to get started if you already know Subversion and you can easily use more advanced features of Mercurial later.
You should be able to find online repository service for your Mercurial repository enabling you to make easy backups and do collaboration some day if you have the need for it.
My recommendation is Mercurial with TortoiseHg.
Solution 11 - Version Control
A source control system doesn't care if there's only one developer involved :)
I would recommend that you use a source control system that you've used before and liked.
If you like vs 2008 integration of the source control system however I would go with http://msdn.microsoft.com/en-us/tfs2008/default.aspx"> TFS although I never had the experience to set it up but it shouldn't be so hard.
Another possibility is to use svn (you'll find some servers on google) and use http://tortoisesvn.tigris.org/">Tortoisesvn</a> that integrates into the windows shell and is nice to work with.
Solution 12 - Version Control
A number of the posts advocate putting the repository on a server because it provides redundancy. I don't think this is all that helpful for a single user. Using a separate server machine adds a lot of complexity, but it doesn't buy much redundancy: if you lose the server machine, you still have the current sources on your development machine, but you may have lost ALL your history. Putting the repository on a server does make sense if that server is being regularly backed up. Using an exernal hosting service for the repository can provide storage redundancy, but you're at the mercy of the external service AND you need an internet connection to access the repository. If you use an external host, make frequent backups of the repository that you keep control of!
I would presonally recommend TortoiseSVN using a local file based repository. Just make sure you backup the local repository to a second machine or external media (such as CD-ROMs) on a regular basis.
Solution 13 - Version Control
I'd recommend two things:
First up, that other server - what happens if your machine dies? the house burns down? etc. Having it on another machine is a good idea from a redundancy point of view.
The second one is WHAT:
If you are very familiar with visual source(un)safe, think about SourceGearVault. It's VERY nice, very fast, and very much a vastly improved "clone" of VSS (ie works the same way from the users POV, not under the hood). Needs SQL server and windows tho (it's .NET + SQL server). Free for 1 user.
Of you are not, then I suggest you do one of two things:
First, get VisualSVN. It's great, works with VS2008 really well. Second, if you MUST run it locally, get VisualSVN server (free!). Make sure you have a good backup plan. Runs on XP/2003/2008/Vista etc.It's just Apache + SVN, under the hood, so it just saves you on the setup - took me 5 mins to install and have it running.
OR, and I prefer this one:
go somewhere like Unfuddle, Dreamhost etc, and get hosting for SVN. It's private, it's fast, and most of all - it's OFFSITE. My dreamhsot account, with something crazy like 500GB of storage and 1-2TB of transfer/month costs about $6/month! There are others which do SVN hosting + bug tracking etc. Look around.
But yeah - SVN is the schizzzznit.you could create a local repository, but I like having a remote, backed up server.
TFS is total, utter overkill for 1 developer (or <5 IMO)
Solution 14 - Version Control
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.
Solution 15 - Version Control
http://bazaar-vcs.org/">Bazaar</a> is a good version control system. I like to use it for my linux configs because you don't need to create a separate repo.
Solution 16 - Version Control
A while back I did a how-to blog post on using SVN with only one developer. I called it Single serving source control
Solution 17 - Version Control
Well, for start, you don't need distributed one :) I'm not sure what this physical part means, because you could put svn server on your own machine in little trouble.
On the other hand, NetBeans have local history module that logs all local changes of a file. Maybe something like that would be enough for you if Visual Studio have something similar.
Solution 18 - Version Control
I would recommend Subversion since it's for single developer and I assume that you're not doing complex merging and lots of log/history checking.
Seems like many people are using <http://svnrepository.com/> for their hosting. It comes with Trac and even Git if you need it later.
Solution 19 - Version Control
Some good answers here.
I want to re-iterate the suggestion to use a separate computer to host the source control server, although it doesn't have to be a dedicated machine. It could be your Windows Home Server box, or some other server you're already running. Or it could be a virtual machine hosted on some other server. Whatever, just make it separate from the machine(s) where you write code.
I also want to suggest that you get a good backup discipline for your server. Something nightly at least; hourly if you can. Back up to a dedicated device (like an external hard drive) or something offsite (a server in your cousin's house in another state) or in the cloud (Amazon S3). Remember that your source code is your key asset; take care of it!
Solution 20 - Version Control
I've been working with Bazaar now for a few weeks and really like it. I'm a linux developer so don't really know much about Tortois but if you like it you should know that there is a Tortoisbzr
Solution 21 - Version Control
Hands down I would use git, and I believe many reasons why a single-developer would like to use git are hinted at or described in git magic
Solution 22 - Version Control
I use Springloops - version control tool for developers
- SVN / Git version control
- Automatic deployment to servers
- Create repositories
- Invite people
- Import files
- Great support
So, try Springloops
Solution 23 - Version Control
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.
Solution 24 - Version Control
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.
Solution 25 - Version Control
I use Perforce as well for my own personal stuff, mainly because we use it at work. There are emacs bindings for it as well, so you can sync, check stuff in or out, etc. all from within emacs.
Solution 26 - Version Control
I recently moved my studio from Subversion to Perforce and put some notes about it, sort of a postmortem, on my blog here. Hope it's useful.