Or would a conventional client-server VCS be more appropriate? I\'m currently using TortoiseSVN, but I\'m interested in a DVCS, but I\'m not sure if it\'s even a good idea to tr
Yes. There are two main reasons I switched to DVCS (Git and Mercurial) for my own hobby projects. First is the issue of keeping backups and the other is that I travel around a lot and use several geographically seperate computers.
I work with at least two repository clones. One is the obvious local one that is with my workspace, the other one is one I keep on my file server (or online repository such as github or bitbucket) that I will dump on whenever I'm finished with stuff locally. Making the backup is as simple as syncing the repositories, in other words pushing your changes upstream.
This is probably something that is less common scenario for developers with hobby projects because I tend to travel around. Aside from my computer at home I sometimes stay over at my parents where I keep my old computer (that is fashionably quick enough for hobby programming). Whenever I feel like hacking new features I can do it on that computer and then just sync repositories so I will receive those changes when I get back home.
It is no secret that DVCS handles branching/merging quite automagically. Merge conflicts do happen, but even without those in a centralized version control tools, e.g. Subversion, doesn't really help out that much with merging even in simple scenarios. Even though I don't use this feature all that often for personal projects there are some developers that do.
I know one programming contractor that used git to keep track on his own work on a proprietary system at company who were still using SourceSafe for version control. Git made it easy for him to keep track of the seperate fixes by branching each fix even though he had to merge the files manually in the end. When the time came for him to check-in files to SourceSafe, he'd be looking at the diffs in the different branches to see what changes were needed and then do them. Lets just say that most of his time was spent on waiting for his peers to catch up.
For a single developer, every VCS will do. I would choose one, that is easy to setup and demands little to no config at all. I personally like Monotone. It was one of the first and I still consider it one of the best ones.
Actually, the most fun I ever had was when using darcs, but it's written in a rather ugly language (Haskell) and it was actually already quite a pain to build it on Mac OS X from source.
Git is said to be a good system, but I dislike that it consists out of multiple binaries and scripts and so on. What I really like about systems like darcs and Monotone is, there is one binary... and that's it. No clutter of binaries, no scripts in this or that language, on binary and it does it all.
I seriously recommend going with a distributed one. On Windows, I chose Mercurial and have been very happy with it.
Big pros:
Cons:
Yes. A DVCS is, in my opinion, even better suited for solo development than a traditional server-based system. A lot of the server-based systems' features are just unnecessary complications when there is a single developer.
On the other hand, you probably won't notice any major productivity differences between a DVCS and SVN if you are solo.
Since you can still push to another machine also running Git/Mercurial/Bzr/etc you still have the multi-computer backup safety, which you'd hopefully have either way. However if you ever code while traveling, having full repository access can be a huge plus, then just resync to your server when you have a net connection again/get home/etc.
I think yes. For one, it scales much better if you use multiple computers because merging is much easier. Second, you can commit offline which is, well, great in general.