This is exactly right:
There are so many good reasons to try one of these new tools out. But I think the most important one comes down to this: just get it out of your head. Just commit the changes. Just start a local repository. Don’t create undue stress and open loops in your head about what, where, or when to import or commit something. Don’t start making copies of ‘index.html’ as ‘index1.html’, ‘index2.html’, index1-older.html’ ‘old/index.html’, ‘older/index.html’ and hope that you’ll remember their relationships to each other in the future. Just do your work, commit the changes, get that stress out of your head. Share the changes when you’re ready.
It’s a much better way of working, even if it’s only for yourself.
I have blocks of code (especially inherited code) still not under revision control simply because there's a little mental hoop to get over in importing them into subversion. First is the difficulty in creating a repo from existing files; I always have to look this up:
From the subversion docs: how to do an "in-place" import# svn mkdir file:///root/svn-repository/etc \ -m "Make a directory in the repository to correspond to /etc" # cd /etc # svn checkout file:///root/svn-repository/etc . # svn add apache samba alsa X11 # svn commit -m "Initial version of my config files"
Ok, that's not really that bad - worse is the decision making process - should I just add this to my "everything repo"? Or is it possible that the customer will want a Trac instance at some point (or someone else will need svn access) and therefore I should make a new repo? (Oh, and since I rarely use the svnadmin command I always have to fumble around creating a new repo. Where's the repo root again? Should I do an http:// (if I need to share at some point) or file:// based repo? Does my new repo need a trunk and branches folder? All that adds up to enough mental friction that I frequently don't bother with revision control until I've been working on something for a while.
Using bazaar-ng all those questions are answered by a quick
#bzr init #bzr add *
There's no reason not to go ahead and do it. And we haven't even gotten to the key benefit of DVCS - much easier branching/pulling/merging operations. I haven't played with git or mercury and only a little bit with darcs. If you've been telling yourself, however, that there's no point in looking at the new generation of distributed revision control systems because you work alone - pick one and try it out. Use it for a week. I bet you'll be suprised...