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.

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.

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

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.

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

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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. :)

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

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.

:)

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.

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.

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

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

4.) git commit

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

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

    git commit -m "<YOUR MESSAGE HERE>"

    This will push back your changes to the master repository.

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.

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

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.

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

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

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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

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.

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?

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

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.

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.

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

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

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.

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 :)

Concerning the question itself: yes. Yes. YES!

Yes.

Yes.

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