Ask HN: Is version control worth learning early on? | Hacker News Reader

Ask HN: Is version control worth learning early on?

70 pointscolbyolson80 comments

Just spent two hours writing a 25line Python script. First real script, totally happy and pleased with myself. But what do I do with it?

I am planning on storing it in my personal Dropbox so I can edit it or create more on which-ever computer I own, but my question is: would it be worth it to learn Git/SVN now, in the early stages of programmer-hood, or later down the road. Would I benefit from learning/using Git/SVN now? Or would I benefit more from ignoring Git/SVN and just focus on writing code. Thanks.

View on HN

Do it.

A night or two spent on learning how to use git (and maybe setting up a remote repo) will save you tons of headaches later and produce lots of benefits almost immediately.

You beat me to it. I agree 100%. Learn to use version control as early as is reasonable. Hell, learn to use it for your personal document directory on your computer at home -- it's great for that, too. It's useful for more than just source code, especially if you want to work on the same stuff on multiple computers.

100% yes.

I've never found myself thinking "I wish I didn't have that version from before that big last change" but I have thought the opposite.

In fact, a few months spent learning best-practices for programming in general (including version control, proper testing, automated deployment, isolated environments, etc.) will pay dividends later. Learn these things now (and apply them even where they aren't necessary, in order to build experience and comfort level) and within a year or two I can practically guarantee you'll be better than at least 90% of working programmers.

There are so many life-altering tools available for developers now; far more than were available when I started programming. Unfortunately, the longer you build up bad (or simply inferior-to-current) programming practices, the harder it is to apply new, better techniques. Integrate them into your life now and you'll have a sturdy, solid foundation to build on.

Quite right. Here is a tutorial covering some of the basic tools.

http://software-carpentry.org/

I'd go so far as to say that every developer should know everything on this page, or at least some substitute (e.g. mercurial instead of svn, ruby or c instead of python).

At the level of 25 line scripts, something like drop box provides about all the headache-prevention and benefits needed. Programming in the large involves a great deal of bookkeeping tasks, which, while important and valuable are about -3.7 on the fun scale. The tools for such tasks also tend to have impressively poor usability.

If you've written a 25 line script, write a 100 line or 5000 line one. And have fun. You already understand the importance of versioning and having reliable backups. Assuming your goal is to become a programmer rather than a book-keeper, stick to the programming for now.

Interesting thought, and you have good points. A 25 line script probably isn't worth the hassle of version control.

The thing is that learning version control is well worth the hassle of version control for someone trying to become a programmer.

Definitely.

One of my favourite interview questions to ask is, what version control systems have you used. I don't really care if it's not what we use. But someone who can't talk fluently about whatever system probably hasn't worked on a large project, probably hasn't worked as part of a team, and probably hasn't had experience dealing with regressions. That's a red flag.

One of my favourite interview questions to ask is, what version control systems have you used.

I always ask what the applicants favourite editor is. Not because they have to use The One True Editor, but because they definitely should have one they prefer (which implies "know"). Craftsmanship warrants knowing your tools.

Learn revision control concepts as soon as possible. This is one of the ancillary things you need to know to become useful to other programmers...those that can teach you.

When you work with teams, in particular, being competent with your revision control system is mandatory. You'll be surprised by how easy it is to pick up the basics, if you just make yourself do it. The Subversion book is quite good both from a conceptual, as well as specific technical perspective; we've just started moving our projects to git (and I've been using VCS of one form or another for more than a decade), so I don't have a good notion of what the git docs are like for complete VCS newbies.

Anyway, create an account at github, follow the tutorials and docs they provide, and you'll be able to do most everything you need. I don't think Subversion will be going away any time soon, but DVCS is definitely rising quickly, and most new OSS projects are starting on git or another DVCS.

When I first learned how to use SVN I found the Subversion book (this one : http://svnbook.red-bean.com/) very confusing. I think it goes in too many details early on.

If I had to do it all over again I would try to find the very basic functions that I have to use and a few graphics explaining how it's structured.

I could never figure out Git until I read this:

http://www.eecs.harvard.edu/~cduan/technical/git/

Lot's of people here are suggesting git. I admit that I never tried it and personally use mercurial hg.

I definitely recommend learning version control as soon as possible. It's a life saver, and it's incredibly easy. With mercurial you're up and running by typing 'hg init'. That's it.

And then you get to experience the satisfaction of 'hg commit'. Maybe I feel like this because I've been burned by not using control version system a long time ago. But really, as soon as I've done a commit, I just feel at peace: I can throw myself in large refactoring (unit test helps too), try something that will probably not work and break everything. It doesn't matter because it's so easy to backtrack.

You can do the same with copy paste. But it takes much much more time. It's just too much of a hassle. And it doesn't scale with teams of more than 1 person...

In basic usage I found hg and git remarkably similar (although I haven't had to do anything further than a clone/co/comit). I'd rather use git just for github (which I find to be the best "social" repository hub) - github has always provided much more than Google Code or Launchpad in that the emphasis is on finding someones repo, forking it and making it better.

I have not tried github, but I find bitbucket (Mercurial hosting) to address your issues properly. Everything else with that site is also right :)

Learning how to use version control is not such a hard enough task that it will honestly "prevent" you from making progress on programming. This is kind of like asking whether you should figure out how to get car insurance, or not get distracted by that and focus "on the driving" instead. Its not that difficult, and you will regret it. On the other hand, I suppose learning to use version control the hard way is arguably one of the most important milestones in a programmer's career.

Don't get me wrong, you can become a master at certain VC systems and do all sorts of neato stuff with them, but you should focus on getting the bare minimum down (enough to just replicate what you are already doing on dropbox, which should take you a few hours max), and then get back to programming. You will learn the rest along the way. At some point you will say "oh man, I can't believe x happened", or "I really wish I could look at my code this way", you'll ask someone for help, and since you were using a version control system all along, you will be able to do it.

Think of it more like getting a proper text editor to replace notepad rather than "learning" something brand new.

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.

Even 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.

I'm not sure moving from hg -> git would be a "step up". It would be a lateral move at best.

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.

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.

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?

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.

http://www.nizkor.org/features/fallacies/appeal-to-authority...

de gustibus pravis? What is pravis?

"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.

I'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.

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.

Why not learn enough basics to at least keep versions of your code around. You never know, perhaps one day you'll find it amusing to track your progress.

You don't have to learn all the ins and outs. I don't know git very well yet. Basically to start use

git init

git add -A

git commit -m "yay, another submit"

Also a .gitignore file might be useful

Absolutely as soon as you start working with other people you will need this knowledge. I wouldn't learn SVN because you can interact with SVN via Git. (git-svn). To get startet:

Git on Windows, how to install and use it (or see below for Tortoise git)

http://www.gitcasts.com/posts/git-on-windows

Mov: http://media.gitcasts.com/c10-windows-git.mov.zip

If you use the Git GUI from Msysgit to clone a repo please use the following credentials: ...

Tortoise Git is a easy solution which is thought to integrate into e.g. Explorer etc. Please see here for details:

http://code.google.com/p/tortoisegit/ (first install msysgit then this..)

Linus Torvalds on Git (a more detailed introduction) http://www.youtube.com/watch?v=4XpnKHJAok8

Git usage: ----------

Most interesting is for git is that "Branching" is very cheap. This means that if you want to implement feature X you just "branch" the repository (e.g. local or remote) and don't affect the main branch until you want to merge your code back into main.

Cloning: ---------

1.) Open e.g. Git Bash

2.) Go to the folder where you want to store the repository

3.) git clone ssh://IP:PORT/REPONAME.git TARGETDIR

4.) It will ask you for your ssh key. (please see the above video (.mov) for details).

Later then you can test things by just changing something slightly and recommiting it, e.g.

1.) cd TARGET

2.) vi README

    # ---> .... changed something

3.) git add *

4.) git commit

    # --> vi will pop up and you type e.g. one line "-

Added some more

    # details to the README file how to do XYZ."
  
    # This can also be done on the commandline by:

    git commit -m "<YOUR MESSAGE HERE>"

5.) git push

    This will push back your changes to the master repository.

Have fun !

I hate to go against the grain, but I would say don't learn version control until you know you have to. The first time you get burned, like just lost a week of work burned, you'll know exactly why version control exists and why you need it.

That being said, I did use vc (cvs, uggh) from pretty early on, but I still got burnt a few times when I forgot to check in or damaged my repos.

Should I wear a seatbelt in my car?

No. That way, when you have a crash and are severely injured, you'll realise that you should have been wearing a seatbelt!

Completely true, of course, but the original poster's use of irony wins more style points than yours. ;)

Irony is judged by how artfully it approaches the line of apparent total sincerity without going over. Your response is clearly ironic. But it's possible to imagine, for a few seconds during the first reading, that the OP is being serious. Only after you think about what he just said do you start laughing.

Man, are you californian? I have noticed that what californians call irony and my own definition are completely different. What you're talking about I'd maybe call deadpanning - sorry, not really up on the various types of comedy. Irony would be more like a guy who had long publicly scorned version control, mocking all who used it, losing all of his code because of some problem which would have been easily avoided by the use of version control.

Guh, reminds me of what my friend used to do. He'd be acting all excited and say "Did you hear? Nine Inch Nails is having a concert here next month!" and I'd be like "Wow, cool, I want to go!" and then he'd crack up laughing and say "I can't believe you thought I was serious".

edit: he didn't deserve to be downvoted .. wtf. Maybe downvoting should cost the downvoter a point too, like on Stack Overflow. Would be an interesting experiment.

if it matters, i doubt many early start-ups worried about or even used version control. we used dropbox when starting out because we never worked on the same code, and we had to hit deadlines quickly. as it turns out, we got funded, and we took the time to polish the code (and implement version control) when we had the opportunity. a vast majority of founders of yc funded start-ups i've asked have told me they did not use version control early on (ie justin.tv and airbnb didn't, although i think reddit always did).

i know for a fact that youtube for example did not touch version control early on. you should definitely appreciate speed when you're starting because your ideas could change (and your code).

it's a trade off, and eventually you'll start doing stuff like unit testing. at some point, the more time you spend perfecting your code, the less time you can spend prototyping and changing the idea if it needs to be changed. i don't think it's comparable to a "wear your seatbelt, you should ALWAYS be using version control in EVERY situation" thing, you should really think about whether you need it. you should worry about hard disk failures, so do a back up every once in a while with a flash drive or dropbox at the very least. but version control has its own learning curve.

A benefit of learning version control early is that once you're good at it, it doesn't slow you down, even in early rapid/solo/investigational work. (The few tiny extra steps it requires quickly pay themselves back by providing de facto backups, reversing wrong turns, helping to debug or reconstruct prior reasoning, etc.)

I would guess most people on their second startups enable version-control from the beginning.

I don't see how version control has an impact on speed...

I think if anything a VCS could make you faster because it frees you from worrying about whether you're going to make a change or delete something you can never undo.

With version control you're always safe in the knowledge that whatever you do, you can always 'revert' to the last version that worked.

As a historical note -- git and hg didn't become popular and trivial to use until the past couple of years. When YouTube was written, free DVCSes were tricky to use, documentation was shakier and the best alternative, SVN, is a pain to set up for sharing over the internet. We're living in enlightened times now.

Yes. The first time you accidentally blow away a bit of code that you spent two days debugging, and can get it back because you check in every night, you will be thankful.

Or if you change a massive chunk of code only to find out your customers HATE it and you must roll-back.

It sounds like you're already getting an overwhelming yes, so I'll just add:

1. It's not a bad idea to keep some of your home directory under VC, especially config / preference files and any writing. (This is more useful on Unix, which typically uses text files for nearly everything.) They're also useful for backup.

2. Git and Mercurial (AKA "hg") are both really good, and probably simpler to use than svn. (I suspect the people who say svn are simpler probably learned it first, and then had to learn all the ways that git/hg's designs differ - but those differences make them simpler to set up.) They havea few different features, but have probably 90%+ in common, and you're not going to really know which one would be a better fit for you until you pick one and learn the basics. You can change your mind later.

Truthfully version control has never really helped me out on anything other than backing up and restoring. I still have to google svn command just to figure out how to go back to previous revisions.

I would recommend you just learn how to set it up and learn a few basic commands like checking in and updating and then see if using them in your workflow helps at all.

If you work on any collaborative projects you'll probably have to use it, but just the basics.

As far as all this talk about good habits, etc. Its all bullshit. Its a tool. If it solves a problem use it, if it doesn't don't sweat it. And when you are eventually forced to use it, just learn a few commands or ask for help. Its really no big deal.

Life insurance is a tool too and I have no idea how to redeem a policy.

There's really nothing to learn. I only know a few commands

svn up svn st svn rename svn add svn remove svn ci

that's all I need to know and I've got by with just that for years.

version control is so essential to the way I work now that I can't even fathom working without it. it's not just about version control for me (I very rarely need to "roll back" code etc), it's more about security, having access anywhere I want (my repositories are remote) and being able to deploy sites with just one line of code instead of faffing over what has changed and what hasn't on the live server.

Yes, yes, yes, yes, yes, yes!!!

I work as a release engineer, and the sheer number of f*-ups that could be avoided by dev's understanding version control better is truly astonishing.

It doesn't matter very much which version control system you use (though there are a few which will give you a pounding headache) it's more important you understand a few useful processes, like merging and conflict resolution, branch strategies (e.g. feature branches, release branches, does HEAD == all source-code?, etc, and why you'd use one or the other) check-in style (e.g. larger chunk(s) with peer code-review?, frequent updates that allow you to follow your thinking at a later date?, pre-submit unit-tests?) among a few other things.

Even though not all of these things will be needed by your project(s), knowing those things in-advance are what will allow you to use a VCS effectively, even if you work alone.

Definitely learn to use version control of some sort (I'm still stuck on Subversion) as early as you possibly can. Indeed, it'll be great to track your progress as you build up code on more complex stuff. Also, you'll definitely be great in a team environment and it'll foster a somewhat safer team environment, too. Teaching a developer now at my job (who was in place before I was) how to use SVN because now we're officially a team and I stay nervous about accidentally hosing anything he does or vice versa.

And yes, being able to rollback bugs or things your users don't like in a systematic, traceable way is absolutely the best. Undo only works up to a point lol.

Check out The Pragmatic Programmer for more nice ideas about being a developer. http://www.pragprog.com/the-pragmatic-programmer

When I first read the question I almost fell off my chair. The answer is YES. I have used source safe, star team (briefly), cvs, svn and now mercurial. I haven't used Git but I understand that it is conceptually similar to mercurial. I keep most everything in mercurial repositories, not just my projects.

I much prefer the distributed stuff. Just make a repository anywhere now it is an awesome concept. Soooo much easier than fiddling with an svn server for example. (I am talking about the set up of the server.)

I personally think it is completely worth it to get your head wrapped around the idea of distributed revision control. Aka mercurial or git.

Rolling eyes and shaking head at all of the other folks on this post who recommended avoiding learning revision control as soon as possible. That would be a mistake.

I'd suggest waiting until you want to start collaborating on a project. My first few scripts used folders for version control, and it was perfectly adequate.

Why wait? Here's a few reasons: 1. If you've only written one script, then your time is better spent learning and working on interesting programming problems.

2. Dropbox includes basic version control. It's more than adequate for a few scripts, with the advantage of being automatic and dead simple.

3. Version control is a pain in the ass. Installing software, setting up ssh keys (if working with a remote repository), and learning the commands was exceptionally boring for me.

There's no need to experience this tediousness right now -- just dig into whatever is the most interesting to you!

+1 for version control.

1) Do it because it will give you a huge piece of mind (backup & history)

2) Do it because you can code review (git diff) the whole feature before committing it, rather than doing it one line at a time and hoping you'll achieve stability in the future.

If you don't take the time to start working with version control from the very beginning, you'll just give yourself bad habits that you will have to break later. Also, you run the risk of losing your code in the event of some catastrophe. I would recommend you use one of the distributed version control systems so that everything for a project (including the entire project history) is self-contained in a single folder. That way, when you upload the data to your dropbox account, the entire project history is archived/backed up. With SVN, you'll have to setup a separate server, which you'd also want to install in your dropbox account.

Absolutely. I'm more of an SVN guy than Git, but you should probably try both to get a feel for what suits you best. Version control is an absolute must for any project above 25 lines.

Learn it early and use it often. It will literally only take a couple of hours to pick up the basics, and then it's jsut practice. Learn more from there as you need to. Even if you're a solo developer, version control is an invaluable tool.

As for which VCS to use, I personally prefer Git. I don't find it difficult to use or awkward at all. I've used SVN in the past and didn't care for it much, though that's probably just a personal preference.

You could view SCM systems as dropboxes for code. When you write code you want to go back and make edits like you said. These tools allow you to do this and keep track of the life of your program and to learn the basics you would only really need to learn how to get the version you want, put back your changes and how to add/remove artifacts from your project.

Git or SVN would be ideal for what you want, a dropbox is less than ideal.

If you're doing python development, I'd suggest learning Mercurial (HG). I actually find it simpler to use than SVN. And Python itself is moving to HG for version control.

Also, if you're on Windows and you want to do SVN, feel free to pick up Tortise SVN. It adds SVN extensions to explorer, and the tutorials are really rather good.

Put your mercurial/git repo in your dropbox! Remote backups + versioning.

What I've never understood is why version control systems cannot just detect if a file has been deleted automatically and remove it from the repo automatically. And link back up to it if it reappears?

VCS all the way, make that your priority. Matter of fact, I use VCS for more than just my program source code; I use it personal documents, files, etc...

Subversion is my preferred tool, others seem to like the GIT/Bazaar/Mercurial bandwagon too though.

I have to recommend the http://progit.org book, because Scott did an amazing job of explaining it step by step in a clear and concise way. It's also free online, which is an obvious bonus.

I would suggest doing it sooner rather than later - there isn't that much to pick up and if you use a hosting service very little to install (I use the free service from Unfuddle - which is more than enough for my personal projects).

Learn some version control and use it. Period. It saved my MTech thesis a couple of times. And that is something. Even if it is for just this one time, blindly take this advice. Will thank HN community later.

Absolutely learn it now. I suggest reading "Pragmatic Version Control Using Git" (Subversion & CVS editions also available), from The Pragmatic Programmers. Excellent book. Short & straightforward.

Learn both SVN and a test framework now. Do it right from the start.

If it seems like too much at first, think of all those programmers who complained about people learning OO or structured programming from the start.

HELL TO THE YES.

I'm not l33t enough yet to check /etc into VC, but everything textual that I work intensively on -- code, writing -- gets its own git repo. It will save your bacon later on down the line: trust me.

Yes. But don't just learn the tool, learn what problem it solves. Tools have changed significantly over the years, but the principles are the same.

Learn git.

It's easy to do and will save you a whole load of ballache down the line.

Our front end designers picked it up pretty easily so it can't be that hard :P

i'd just write code. in fact, we used dropbox as our version control system for a month or so in the early days. you'll need to figure it out eventually, but get your bearings first.

learn a version control. If get/svn is to complex, use rcs. Really, if I was learning today I would start with git.

But what you choose does not really matter. Learn a revision control system.

svn update

svn add newFiles

svn commit -m "I did something"

There's not really all that more to learn, just check the docs or "svn help" but it'll certainly be well worth your time to get into the habit.

That's way more than I've ever learned about SVN, and I use it every day. Download a copy of TortoiseSVN and right-click your way to happiness.

True, although depends on if you're naturally a mousey person or a keyboard/shell person.

For some reason I have an instant distrust of anything mousey - seems like a barrier between me and what is really going on. But as you say good option for those who prefer working that way :)

learn svn, because it's like the english language of version control. then, move on.

I see a lot of people suggesting git, but I understand the interface is still rather, ehmmm, user hostile, with lots of obscure options, which makes it a lot harder to understand. Perhaps it would be easier to start with svn, using http://svnbook.red-bean.com/.

Concerning the question itself: yes. Yes. YES!

I'm using git because that's what I ran into first, but mercurial seems to be nicer from that point of view.

Yes.

ohmygod, learn version control from the get-go.

http://www-cs-students.stanford.edu/~blynn/gitmagic/

from the git-go?

Reply on news.ycombinator.com