views:

452

answers:

6

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 try to use something like that solo.

+5  A: 

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.

Denis Bueno
Well, the offline thing doesn't matter if your development computer IS the SVN server. I don't usually commit when I can't use my computer. But the first point is valid.
Thomas Owens
Arguably it's wise to keep a seperate copy of your repo on another computer because that will be "backed up" more often then most single person's backup habits, so that if either machine goes down you still have another copy. Better safe then sorry with source code.
Runevault
I use my desktop and laptop to do dev work. The desktop is the SVN server. Obviously, when I'm out and need to commit from my laptop... DVCS rulez
Jrgns
Belatedly - if the dev computer *is* the server you have a problem you need version control to include getting a copy onto a different machine (ideally a different machine *and* a different location - but that can be covered by backups)
Murph
+14  A: 

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.

Runevault
<http://git-scm.com/> <http://www.selenic.com/mercurial/wiki/index.cgi> <http://www.monotone.ca/> <http://www.bitkeeper.com/> <http://fossil-scm.org> I use fossil, but I checked out Git and Mercurial first. I just thought there should be links for convenience.
javelinBCD
+1  A: 

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.

Mecki
Fortunately, in Git 1.6, the supporting binaries are at least installed in $PREFIX/share/git-core/.Although I personally like the separate binaries, because it makes it really easy to write shell scripts -- or even compiled programs -- to extend the functionality of Git.
mipadi
+9  A: 

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.

Kristopher Johnson
You will notice far superior merging with bzr/git/mercurial as compared to subversion.
Hamish Downer
But as a solo developer, merging probably won't happen all that often.
Kristopher Johnson
Merging happens, because you want to stabilize a branch, but want to work on new features. For bugfixes and similar stuff you have to fix it on all branches, so merging is needed.
Mnementh
+3  A: 

I seriously recommend going with a distributed one. On Windows, I chose Mercurial and have been very happy with it.

Big pros:

  • Local commits are fast, can commit often (Test, Code, Refactor, Commit)
  • Branching is simple
  • You can commit wherever you are.
  • Simple to move files around (No more mess like I use to get into with SVN)
  • Just simpler. One software does it all (including admin tasks)
  • File system is cleaner. No more .svn everywhere, just one folder
  • List of ignored files is just another file in the repository and gets automatically copied to every clone. Easier to keep clean than SVN again.
  • Bitbucket.com is nice and gives one free private repository

Cons:

  • (For some) GUI tools are not there
  • You will probably need SVN still to connect to various source repositories. E.g. need to use two systems.
mmiika
+1  A: 

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.

Quick and Easy backup

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.

Work on different locations or computers

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.

Easy branching/merging

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.

Spoike