OK, there's several things to address here.
First things first: get some version control, right now. Even if you're never going to collaborate with other people, you'll learn to appreciate it. VCS serves as part of a backup scheme, it's easier to find particular versions of your source code than dealing with timestamped copies, and once you become disciplined and write proper commit messages and commit at a proper granularity, you'll see you have some powerful tools at hand to search history, track regressions, managed branches et cetera. It does take a bit getting really used to VCS and reap all the benefits, but it's worth investing time in it.
Next, move to either Mercurial or Git right away, go right past Subversion and don't collect the... oh wait, this isn't monopoly. But do avoid svn even if you aren't going to use the distributed features of Hg or Git. Why? If nothing else, speed. A list:
- Fetching the entire Notepad++ Community Release wia Git via my 20mbit ADSL is faster than grabbing fSekrit with subversion on my gigabit LAN. Nuff' said?
- Since dvcs store all files locally in addition to the (optional) remote repository, switching branches or datamining history is lightning fast. With subversion, even on a gigabit lan some operations can be painfully slow.
- Subversion stores it's info in ".svn" folders in each and every subfolder of your project. This is ugly, it means you have to use "svn export" to grab/export a clean subtree, and if you forget to do this and copy subfolders around in your svn-managed project, you can screw things up majorly. Both Hg and Git use a single top-level folder per project.
- Even though subversion has metadata scattered in all those .svn folders, you don't have the full project history locally - so if your remote repository goes AWOL, you're screwed. With Hg and Git, your own machine has a full local copy of all history.
- Subversion doesn't treat branches and tags specially, but just as part of the filesystem. This does, kinda, give you some flexibility, but it's flex you don't need, and it can cause a lot of clutter and fuss if you aren't very disciplined with how you arrange stuff.
- Branches in svn always go to your repository, meaning they're slightly slow operations to perform, they "pollute" the namespace, etc. Thus, with svn, you think a lot before you make a branch, especially on a multi-dev project. With Hg and Git, you can do local "feature branches" to work on without disturbing other people, and merge those to the current working branch before pushing your changes upstream. In other words, YOU have a lot of flexibility on your own machine, without necessarily cluttering things for everybody else. Even on single-dev projects, it's nice being able to take a break from adding a new feature to fix a bug, and then merge it all together.
Tortoise is available for Mercurial as well as Git, even if not entirely as polished as TortoiseSvn. Git is probably the system that feels least polished at the moment, but it's entirely usable.
I'm not sure which one to recommend, though. Git does have all the geekboypowerhead features, and you can definitely blast off your legs with the command line tool... But if you stick with basic features, it's really not that bad. Both Hg and Git can be used for pretty much the same workflow as you have with Subversion, so IMHO there's not much use to stick with svn unless you
have to for interop reasons.
You should probably start by checking out Mercurial and TortoiseHg. Chances are you won't need to look at any of the other projects after that. And if you stay clear of svn, you won't need to muck around with converting your repositories when you feel like ditching it at some later point
Recent Posts
