Source Control - If, Why, How to start?

Question

Possible Duplicate:
Using Source Control

So, although even here on stackoverflow are literally dozens things on version control, i can't find something nice to answer all my questions. If you have anything to say or post a link, please do it here.

1., Do I need to start with version control?

While most people agree, that even single developer/programmer should start with version control, nobody (or at least in understandable form) tells

2., How?

In my nature is that I need to know what means CVS, SVN, Tortoise, Git, GitHub and what are the differences, but I struggle to find some dead simple kick-start into world of version control.

As a developer/programmer, I worked or studied almost every programming/markup language, that is major (from pascal to java, from html to php :) ) and used dozens of editors, IDEs and programms. And when somebody mentions you can use source control even for writing stuff - homeworks for studens, annual reports, books... You have to include even more editors...

I have by now no clue how to start with version control, how to incorporate it in my workflow, if do I need server or what.

Thank you for any help in finding what is what and what to do with it :)

EDIT: From all your answers (thank you), I get the feeling it's really only something like "synced folders with history". (in the most obvious way :) ) If yes, can you answer two questions? (numbered 4. and 5., so it wont mix up in answers :) )

4., what if I decide to completely change structure of my program (for ex. in flex, i decide to use two as3 class instead for MXML components) - won't it make confusion?

5., From other questions, how ofted do I commit? (found this question posted and probably answered, lost it again however)

EDIT 2: Again, more answers (thank you)

6., My question 4 was more like if I accidentally (or not) renew some deleted files (which is probably possible), and it will break my program, because for example it depends on other deleted file, which was not undelete, will I be able to get it? :D

7., I see some ways I will look. Thank you for your answers... however, now I'm confused to whom should I give the "good answer", because you were all very helpful :)

Next, I will (for anyone looking for I was looking for and stumbling upon this question):

Read this stackoverflows:

• http://stackoverflow.com/questions/1113412/using-source-control
• http://stackoverflow.com/questions/326429/what-version-control-system-is-most-trivial-to-set-up-and-use-for-toy-projects

Watch this video:

http://excess.org/article/2008/07/ogre-git-tutorial/

While understanding the basics from manuals, I narrowed it down to subversion(+TortoiseSVN) and git(hub), which are most used and most favorited. Only problem I now have with github is that private repository is paid, so I will either look fro different git solution or look more into Subversion.

Big thank you to everyone, I upvoted most helpful answers, also thank you for comments. Adam

Edit: Tried Mercurial, but found it not OK for my workflow... now trying subversion, so I marked oldest subversion answer :)

Answer 1

1. Yes, of course.
2. Start with Subversion and the TortoiseSVN client. It's got excellent support, great tools and is generally far more straighforward to configure and use than Git is.

There's an excellent Subversion manual available for free.

Answer 2

Regarding source control you might want to look at this "How to use SVN, Branch? Tag? Trunk?".

And about using some kind of source control, it's always good to have revisions of your code and documents regading the software development. It might be worth looking in to GIT.

Answer 3

Hi

1. Yes you need to have version control.

2. I suggest you install Subversion on your PC (whatever o/s you have installed). If you are working on windows also get TortoiseSVN, it's the best client for Subversion. The Subversion server runs just fine on a PC.

3. Download and read the Subversion manual. One of the early chapters provides answers to a lot of your questions, not all of them too biased in favour of Subversion.

Yes, there are other VC systems available, but for the lone learner I thoroughly recommend Subversion+TortoiseSVN.

HTH

Mark

Answer 4

I'm going to go against the current grain and say go with Git. It's what I did, rather than learning SVN. Read through the first bit of the git book.

Once you've got the hang of it, it's really straightforward to use. Want to start a new repository in the current directory?

git init

Want to commit everything with a short commit message?

git commit -am 'My commit message here'

It's really not rocket science, as some would have you believe.

And for a lone developer, it's really straightforward. You don't have to bother with a separate repo, the repo is in your working directory.

Edit: You also asked about github. They have really idiot-proof guides to getting started. When you sign up for an account and add a new repository, they give you the exact commands needed to sync it up with your local repo. That's another good reason to use the command line.

Why use github? If your computer blows up, there's a copy in the cloud. If you want to collaborate with a friend, send them a link and they can pull from github - v. straightforward.

Edit2:

4: This won't cause any problems.

5: I can't speak for SVN, but from everything I've heard, because git makes it so easy to commit, you can commit a lot more often, which gives you more granular control over your history. So, say you make a massive error, that breaks everything, and you made it some time a week ago, you can go through your git log and work out where the change happened and fix it. As for actual frequency, I commit about once per half hour (once per pomodoro really), but if there are a lot of changes happening, maybe more often.

Answer 5

The decision whether or not to use source control really depends on your needs. For a single developer type atmosphere and small projects, you would likely just be using it for versioning; making it possible to make changes to your code without worrying about losing something you already did that was working. This sort of sounds like where you are at so I wouldn't get wrapped up in every aspect of source control. If you don't care about keeping these versions and are willing to risk losing stuff, then source control may be an overhead you don't need.

Most people here are going to say Subversion (SVN) is the way to go, and they are probably right. Not neccessarily because it's the best tool out there, but because it is free and fairly easy to understand and use. It's also widely embraced by the open source community which means there is lots of info on the web about it. TortoiseSVN even works mostly from the context (right-click) menu in Windows so you can avoid any additional "editors".

Answer 6

Even as a single developer there are a number of benefits in using some form of version control. For me the most important reason is that if you screw up your source code (if you for instance make a number of large edits and your program stops working) you can revert to a previous working version. So on the first question I would say: "Yes definitely!".

If you don't have any problem with making your code open source there are a number of sites that can host your project for free, for instance google and sourceforge. Otherwise you can run a subversion, cvs, etc server on your own computer.

As for the workflow, most version control software (VCS) works something like this:

• You point the VCS at a file tree on your disk which contains your source file and ask it to create a repository of it on your server (this is done once, when you set up the VCS)
• You edit some files in the file tree
• You inform the VCS that there are changes in the file tree that you would like to send to the server. This is can usually be done from a command line or from some sort of GUI. This operation is often referred to as a commit.
• The server keeps a record of all changes made to each file

For question 4: Most VCS has support for moving/renaming files and this will go into the history as well, so this shouldn't lead to any confusion.

For question 5: As often as possible. At work I commit as soon as I've made any change that I've verified is working. In a multi user scenario it's considered a cardinal sin to break the build, i.e. commit a non compiling/non working version since this brings the other developers to a screeching halt if the update their code. If you are the only developer you can be somewhat more lax I think.

Answer 7

The other answers are spot on. However, I'd also mention that there are two different "styles" of source control:
1) centralized = you store your code in a server, although this may be your local machine (e.g. CVS, SVN)
2) distributed = you store your code in a local database (e.g. Git, Mercurial)

SVN is pretty much the defacto standard centralized source control program, although you'll need to setup its server in order to use it. Not too hard, but you could try a distributed system like Mercurial (http://mercurial.selenic.com/) to cut-out an extra step.

Answer 8

You say you are looking for a "dead simple kick-start", in which case I would recommend Git. Once the tool is installed

git init

initialises a repository in the current directory.

git add yourfiles

to add the files you want to control, and

git commit -ma "commit message"

to commit changes.

The Github Guides are an excellent resource for getting starting with using Git on most platforms, and contains many useful links.

Answer 9

Version control (tools and practices) is something every serious programmer should know. I recommend that you learn some basic systems and get familiar with the ideas as early as possible.

Version control systems come in various flavours. You might have come across terms like centralised, distributed, local etc. which can be confusing to the uninitiated. Most good books on any version control system (the Subversion book for Subversion and the Pro git book for git for example) will give you some introduction to version control itself (divorced from the actual tool they cover). I also recommend the Wikipedia page and this page for a quick intro.

Once you're done, pick up a system. There are many to choose from but their philosophies are different. SVN, CVS etc. are centralised and have lost ground to the newer ones like git and mercurial which are distributed. I would recommend that you first try and use subversion (since it's still widely used and the skill will be useful) and then any distributed one (my personal favourite is git).

The final act of learning will come only with practice and experience and not from reading a book. Good luck. :)

Answer 10

For your new questions:

4: Restructuring your application will not be a problem. They just see some files are removed and others added.

5: As often as you like. The more often you commit, the more easier it is to repair little mistakes.

Answer 11

An answer to your edit, points 4 and 5 (noting that my vote is for GIT - we use it here (multi user windows environment) and it's really been very effective:

4., what if I decide to completely change structure of my program?

Most version control systems will be able to deal with this. At the end of the day, when you commit your changes, you have a version saved of how your files look at a particular point in time, which should be all you need to compile your code.

Your version control system is just an 'easy' way to take a snapshot of your files at a point in time.

5., From other questions, how ofted do I commit?

As often as you can. Or to put it another way, if you change something (or more importantly, accidentally delete something or do something really stupid) and you get the ball clenching feeling that you've just lost hours of relatively unrelated work that could have been committed (and saved), then you're not committing often enough.

Answer 12

Why? I do a lot of work on my own and commercially, I would never, never start a semi-serious project without source control. Over the years I've lost way too many demos (I do a lot of teaching) and other code that I think the safety net of source control is vital. I also run more than one machine (at least a laptop and a desktop), this means that I can do commits and checkouts from multiple locations.

How? For my setup I have subversion hosted on Apache running on Windows. This was on Linux but I moved it for various non-technical reasons. It's running in a VMWare virtual machine. I don't know for sure, but I wouldn't be surprised if there was a VMWare appliance for this - I'm pretty sure there's a VMWare appliance for Apache. The setup is simple and requires essentially no administration other than when I want to add a new project to version control. My server is exposed to the outside world so I can access it from anywhere, you could simply have the server on your home network if necessary.

Like I said I use subversion. I also have git installed on a server but haven't switched over to git, partly due to inertia on my part and partly due to the tools. Today I'm working mostly in .net and Visual Studio on Windows so I like tools integrated into Visual Studio, not that I'm averse to running command line tools, it's just easier if they're integrated.

As for changing the program structure - the main advantage of version control in this case is that if you screw up badly, you can go back again. You can even try things out and throw the changes away if they don't work by, for example, branching your current main line of development. If I was attempting a major re-structure I would probably branch my code base, re-structure to get everything work, then move that branch over the 'trunk' (in svn terms). You don't have to do things that way but it gives you a safety net.

How often should I commit? It depends! For code, probably on a unit of work (which could be as little as adding a single test, or as much as adding a feature), checked in code should always build. For documents, less frequently. You may also have company policies on this, and mechanisms such as shelving (in VSTS) where you can store code in the repository without checking in. Remember the repository is there to a) keep your code safe b) to hold the latest copy of the code and c) to allow the code to be shared. For b) and c) to be satisfied the code should be buildable and pass all tests, so don't check in code arbitrarily.

Hope this helps

Answer 13

On the solitary hobby side of things, source control solves three problems for me.

1. Backup in case of hardware/software/wetware failure
2. Easy synchronization between different machines (laptop, desktop, friend's computer)
3. But, the game changer for me was Git's strong support for branching.

Let me expand on #1. Besides the uncontrollable failure cases, I can go off and do speculative development and if/when the speculation fails going back to a stable base is easy.

Let me expand on #3 for a second. I always have a fairly large list of features I want to add to the software I'm writing. I create a branch for a feature I want to add and can work on it for a while. If later, I feel the desire to work on a different feature, I can go back to a working base and work on the other feature for a while. When I'm happy with any/all of the changes, merging it all together is easy.

I've used SourceSafe, ClearCase, CVS, SVN, SCCS, RCS, and Git in development, and for me the tool that got me using version control on a regular basis in hobby programming was Git. It not only got out of my way, but it made the above mentioned tasks easier.

Answer 14

Yes!Yes! please start with Git.

Am a developer with a habit of trying new things/methods to an already stable application. Before i met Git i kept copying my current stable project to a folder an date stamp the folder just to remember where i was and which was the stable version, then i would start toying around with the code.

But with Git i have no problem trying new tricks on my code, what i do is just branch from my master (main stable app) do my tries, and if i fail in what i was attempting i just discard the branch and switch back to my Master quickly which is still intact, safe and stable. And if am successful (which most of the time am not ) i just Merge the branch to the master, then discard the branch. How nice.

Branching in Git was what made me fall head over heels with it. Try it

Answer 15

1. It's a good idea to start with version control. With very few exceptions, every software business out there is going to be using some form of version control, so the more experience you have, the better. Plus, source control is just a good idea, and I use it for nearly everything I do. Example: every time I send my resume to a potential employer I tag that version. Now I've got a permanent snapshot of what that resume looked like at any give time.

2. How: How depends on what system you decide to go with. I'm going to add my 2 cents to the discussions and put in a vote for Git. Once Git is installed, branching, committing, creating a repository; these things are all super easy and super fast. For lone developers the lack of a central repository makes setup much easier, too. I will disagree with everyone who said learning Git was easy, though. Some of the commands are so esoteric you may never be able to wean yourself from frequent glances at the documentation. (git push origin :some-branch anyone?)

3. You didn't have a question #3, so I provide a link: http://gitready.com/

4. Completely changing the structure of your program is no problem at all. Commit before you make the changes, commit again after you make the changes, you'll be able to roll everything back if you screw stuff up. Another benefit of going with Git is that Git will track text across multiple files. So for example, if Alice writes 20 lines of code in file A.m and Bob moves those 20 lines of code into file B.m, Git will allow you to trace the source of that code back to Alice.

5. I commit constantly, almost every change I make gets a commit and a description. Don't forget the commit message! Having a list of 100 commits with nothing but timestamps will do you almost no good. When I'm doing a lot of GUI tweaking and/or refactoring, i'll frequently spend more time writing commit messages then I do writing code... but the one time that a 2 character edit 17 commits ago breaks my test cases, I'll be glad that I was so liberal and verbose with my commits.

6. Yes. Sometimes it takes some effort to get things sorted out, but if you're moderately careful, your data is rarely gone for good.

7. If nobody else wants it, I'll take it. ;-)

Answer 16

I do have to add my vote for mercurial. Can't leave the limelight all to git. ;-)

But whatever you choose in the end, do start using one. I'm frankly astounded that you worked with all these languages/tools and never started with any VCS. Me, I started RCS the moment I learned about it (way back on the venerable Amiga 1000, w/o a HD, only 176KB floppy disks :) ). Couldn't imagine not using a VCS of some sort. I actually still use RCS, for single files that don't need anything fancy.