Almost anyone who has worked on a software development company is likely to know this already, but I've met many independent or amateur developers that had been working even years without this more than vital tool called Subversion (SVN).

Ever made a change in your code that screwed everything up and spent hours or even days undoing?
Ever wanted to check out a piece of code that got faded away from your project many changes ago?
Ever lost an entire project out of disk or OS failure?
Ever suffered the tedious work of combining your changes to a projects with the changes of a partner in a team project?


SVN services solve all this problems quite simply, for those who don't know this SVN is an online hosting serivce that allows you to upload not just files, but different versions of the same code file and stores only the changes, allowing you to check or even revert to previous versions with a few clicks as well as quickly combining changes from different developers.

If any of you have not used this tool and would be interested in learning more, just post a reply here and I'll post a more extense information on this.

The vital thing is called "Version Control". SVN is one approach to it. Using a distributed version control system such as Git or Mercurial is becoming more and more popular.

If you are new to version control, I would recommend you go for a distributed one.

Well, the main thing to know about svn is that runs on a server computer, this can be done on any personal computer, but I've never done that.

However, there are many online sites that provide this service for you, some payed and some for free, google has a free subversion hosting serivce, I think it was code.google.com, http://www.assembla.com/ is another similar service that I've grown very fond of for personal uses, although most of the additional features have been falling into the payed service packages, svn is still free in assembla.

These pages provide the hosting and storage service. To interact with them however, you need a service client, the most popular free SVN Client is Tortoise SVN, http://tortoisesvn.net/downloads.html
This installs a small interface that allows you to upload and download your changes and other peoples changes if there is more than one developer involved.


You might already used this interface if you worked with svn before, however I will provide a small summary of use just in case for you and other people.

First of, you need to have an svn repository, this is, the hosting service already created, either in a personal computer or in one of the above mentioned pages.

Once you have the URL of that repository, for example http://code.google.com/projects/mytestproject you need to do a repository checkout.

Create somewhere in your disc the directory in which you will like to work, then right click on it and the new contextual interface added by tortoise will display new options, click on SVN Checkout, put your url in the proper field on the menu that got opened and voila! you have a subversioned empty directory.

Create your project inside that directory and add some basic code.

Now to keep in mind, not every file in the directory will be versioned, in fact, by default none of them will, you must manually choose what files to add, this is done by multiple-selecting the files and directories you want to be subversioned and right clicking, under the tortoise sub menu there is the add option, you click that to add stuff.

What DO we want subversioned? if you subversion everything indiscriminately your repository will quickly fill up with unnecessary data (free repositories tend to have a space limit).
You want to subversion only the files that will be necessary to be able to work from another computer, for instance, every temporary or dynamically generated file, such as the compiled binaries of the project, are not necessary, if you have the solution, projects and source code, you can compile on any computer with the development software installed.
Avoid versioning intellisense databases and such since they are dynamically generated and tend to be VERY heavy.
Content is optional, if you have a very large project with gigs of models, textures and such, an svn repository might get filled very quickly, so you might want to handle that some other way, if it is small you might version your content too.
Keep in mind that unlike text files such as code, text and xmls, content such as textures, models and binary files will be duplicated.


When you commit a change in a code, SVN only stores the difference between your new code and the previous file version, if you changed about 15 lines in a 500 line code file, only 15 lines of text are commited, and then mixed with the original file, optimizing the weight of your repository, all the way back to the original file as it was added.
This way Svn can handle text files very efficiently, but with content files it cannot distinguish the relative changes, if you changed one pixel in a 512x512 texture, the ENTIRE texture will be uploaded, and since previous versions are preserved, you just duplicated the file.


Now, for general use rules, assuming you are working with another developer, before beginning to work, right click your repository root directory and update, this will download any changes made by others since the last time you updated, compile to check if any of the new code has created errors, make your changes, once you are finished for the day, update again!, if you have been working for hours, new changes might have been commited by other developers, if there was, compile again to make sure no new errors have arisen, and now you can commit your changes.
As a rule try not to commit code that does not compile or that crashes the application on runtime if you know it does. It is best to comment new code before commiting it if it's not done yet, so you don't screw the project for other developers.


Another good practice is to always fill the commit summary with short description of the changes you are uploading both for other people to know what's new and for you to be able to check back afterwards when a specific change was introduced.

To sum up:

Checkout the project.





Update

Compile

Work

Update

Compile again and fix any errors

Remember to add any new files you have created or other people will get errors of missing files they cannot fix without you

Commit.

The vital thing is called "Version Control". SVN is one approach to it. Using a distributed version control system such as Git or Mercurial is becoming more and more popular.

If you are new to version control, I would recommend you go for a distributed one.

That's right, thanks for the observation, I was not being accurate.

I've found something better than SVN, and that is GIT. TortoiseGit makes Version Control so much better (particularly when merging two branches from different users). It also makes commit-early-commit-often a methodology to live by. I have many Subversion repositories still, I have TortoiseSVN for managing those if I want to go back to SVN, but GIT-SVN provides me local GIT functionality for remote SVN repositories.

I recommend using either SVN or GIT for source revisioning. I also recommend backing up your repositories often to an offsite location (if you can, otherwise a USB stick which stays with you is a nice alternate backup location)

That is because you have not experienced the joyous epiphany that is Git.

+1 Absolutely right! Git is the win. Only caveat is if you have Unicode filenames/folders ... Doesn't encode/decode properly on Windows (or at least not from Linux->Windows). Best for merging and local commits though by far.