6 ms·
Sweet jumping jesus YES. And don't start withi git - start with subversion, and move on to git or mercurial later. Subversion is much easier to start out with.
by discojesus 17y ago
Sweet jumping jesus YES.
And don't start withi git - start with subversion, and move on to git or mercurial later. Subversion is much easier to start out with.
- moe 17y agoEven as a git user I'd second that (blasphemy). 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.
- JshWright 17y agoI'm not sure moving from hg -> git would be a "step up". It would be a lateral move at best.
- discojesus 17y agoStart 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.
- gcv 17y agoSubversion 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.
- discojesus 17y agoshrug 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.
- calambrac 17y agoEric Sink, author of a competing non-distributed version control system?
- discojesus 17y agoEric 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. :)
- calambrac 17y agoI 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. http://www.nizkor.org/features/fallacies/appeal-to-authority.html http://www.nizkor.org/features/fallacies/appeal-to-authority...
- idlewords 17y agode gustibus pravis? What is pravis?
- calambrac 17y agoWhy 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.
- discojesus 17y agoWhy 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.
- calambrac 17y agothe 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.
- discojesus 17y agoI'm pretty sure you just made that up. 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.