|
Subversion is much easier to start out with. False. 1. Subversion requires you to use tools which are Subversion-aware. If happen to delete or rename a file from the Finder, Windows Explorer without Tortoise, or the command line without using "svn rm", Subversion will muck things up, and you won't even notice until you try to commit. And heaven help you if you try to use a non-Subversion-aware IDE. If you're just starting out, you might not know that you must install Subclipse in Eclipse. If you don't, a simple class rename will leave your working copy in a state from which it'll take a lot of painful work to recover. 2. Subversion requires a separate repository to be set up. Often, this means either setting up a whole server for Subversion itself or a web server to serve up the repository over the WebDAV front end. Yes, I know you can just use a local directory, except you still have to read the documentation about how to do it right. Either way, typing "git init" or "hg init" right in the directory where you started hacking takes a lot less effort. Look, I kind of understand that some people think that Git's index takes some getting used to. I disagree, and consider the index an important feature, but de gustibus pravis non disputandum est, and all that. In that case, try Mercurial. It's a perfectly fine VCS. It probably is a bit more intuitive than Git for the first fifteen minutes. Don't worry about either system's more advanced features yet. As a beginner, just get used to saving incremental changes to your code and the ability to experiment safely, and look at what has changed. Eventually, you'll find yourself saying "hey, I wish I could track my code in such-and-such a way," and when you do, Git and Mercurial both have solid documentation. Setting up a Subversion server won't help you become a better programmer. Wondering what went wrong when Subversion thoughtfully breaks your working copy won't make you feel happy about using version control. Even worse, looking at the behaviors of some programmers I've worked with, Subversion teaches people really bad source control habits --- making commits with tons of random unrelated changes jumbled together. |
personally, I agree with him, and given that the issue at hand is "what should this guy start out with to gain the habit of using version control" and not "what is the most awesome version control system ever where you could just imagine a merge and it does it for you while you're on an airplane using a hand-cranked One Laptop Per Child", I think conceptual ease is what we're really going for here.