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.
shrug Eric Sink said it himself: "DVCS's and git are conceptually much harder than tools like Subversion"
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.
Eric Sink, author of a competing non-distributed version control system?
yeah he's only interested in promoting Vault. Except he didn't mention Vault at all during that exchange on DVCS - he only mentioned Subversion as an alternative non-distributed version control system, and he said that DVCS systems were definitely going to be the norm in the future. So, uh, no. :)
I didn't say he was only interested in promoting Vault, or that he was being dishonest. Conflict of interest doesn't have to be some evil shadowy plot. Given that he's spent years working on his system and convincing himself it's The Right Way, DVCS probably is more difficult conceptually to him. That doesn't make him bad or a shill, it just means you shouldn't necessarily take his word as the authority for vcs newcomers.
"Pravus" means crooked, faulty, or bad. I'm pretty sure "pravis" is the correct declension to match "gustibus" (a declension "gustus"), but my Latin has unfortunately atrophied substantially from lack of use.
So basically, I changed the proverb from "it is not appropriate to discuss tastes" to "it is not appropriate to discuss bad tastes" --- and left it intentionally vague as to who has bad taste: people who like Git's index, or people who don't.
Why do you think subversion is easier to start with? You have to understand the difference between the local copy and the repository, you have to manage the server, you might have to deal with the incredibly painful corruption issues that pop up every now and then.
And I personally don't think the day-to-day use is any easier, either, unless you're only working with one branch, and even then, the only 'savings' is you don't have to stage first.
Why do you think subversion is easier to start with?
the program model of a system like subversion pretty much == the user model for source control for someone who is new to source control. Hence, easy to start with.
You have to understand the difference between the local copy and the repository
Which is about as hard as understanding the difference between "your wallet" and "the bank."
And I personally don't think the day-to-day use is any easier, either, unless you're only working with one branch
Which he would be almost all of the time, and when he comes to grok version control pretty well (as stated) he could certainly move on to something like git.
the program model of a system like subversion pretty much == the user model for source control for someone who is new to source control.
I'm pretty sure you just made that up.
Which is about as hard as understanding the difference between "your wallet" and "the bank."
Once you've grokked it, yes, it's simple, but if you're managing your own system on your laptop, for instance, it is a bit of a leap to wonder why you have to install the server in one place and work in another, etc. It's not that it's hard, it's that it's harder than git.
I like how you chopped off the "and even then, the only 'savings' is you don't have to stage first" part of my statement about working with only one branch.
Sorry, I'm going to go with Eric Sink's opinion on this over yours (nothing personal). It seems pretty obvious to me that subversion's program model is way closer to the naive user model than git's is. And yes, that is an advantage, since the user has explicitly stated that he is an absolute beginner to source control.
Once you've grokked it, yes, it's simple, but if you're managing your own system on your laptop, for instance, it is a bit of a leap to wonder why you have to install the server in one place and work in another, etc.
He doesn't need to do that at all - for example, if he's running a windows machine, he can just install TortoiseSVN and set up repositories on his local machine. Dead simple.
It's not that it's hard, it's that it's harder than git.
I'm pretty sure you just made that up.
I like how you chopped off the "and even then, the only 'savings' is you don't have to stage first" part of my statement about working with only one branch.
Because it's false - the "only savings" an absolute beginning user gets is that it is much easier to grok than git if you're new to source control.
Sorry, but this will have to end here - this is getting pretty inane. If you feel that git is obviously much easier than SVN for an absolute beginner, fire of an email to Eric Sink and argue with him.
It seems pretty obvious to me that subversion's program model is way closer to the naive user model than git's is.
You assert this without saying why, except to say Eric Sink said it first. You could at least provide a link to his explanation, I couldn't find the magic Google incantation to find it myself.
He doesn't need to do that at all - for example, if he's running a windows machine, he can just install TortoiseSVN and set up repositories on his local machine. Dead simple.
My bad, I misused the word server. I meant that best case you're still setting up the repository in one folder and then doing all your work in another. On the premise that managing and understanding why you're managing two places is harder than just working in one, git is simpler. I didn't just make that up, that's how the systems work.
Git is the "real deal" but it also has a ridiculous learning curve when it comes to using it right (i.e. never commit to the master branch directly) and many sharp edges to frustrate you.
Start with svn or mercurial to get a feel for what it's all about. You can always step up to git when they don't cut it anymore.
Start with svn or mercurial to get a feel for what it's all about. You can always step up to git when they don't cut it anymore.
exactly - if he starts out with something like git, he's probably going to burn out and have a bad impression of source control, which doesn't help anybody.
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.