This is pretty popular on the windows platform.

http://tortoisesvn.tigris.org

I also would like to know how Tortoise works. Thank You.

You need to have a repository set up at a location you can all access. This *could* be a networked drive or it could be a website that supports repositories. There are free hosts for code repositories, but the ones I am aware of keep the code open source. I've never set one up from a website just for my own personal use to have revision control and I use an internet based repository for work. However there are really 3 main steps to get started.

1)Create the repository. How you do this depends on where you store it. If it is 'local' (ie on a drive in your computer) it would be as easy as picking a location to store the repository (NOT the code itself, by the way) such as DRIVE:\ProjectName-Repo\ then, inside the directory, right click -> tortoise svn -> create repository here.

2)Import the existing project files. This is roughly the same locally as over the internet. Go to the directory you wish to add, righ click -> tortoise svn -> import. You will be given the option to choose what repository to import at. If locally it will be something like file:///Drive:/ProjectName-Repo/ over over the internet at something like svn://website.com:3580/repos/ProjectName-Repo

edit: step 3 is done by each person in the project to get started.

3)Check out the project. Pick a spot to put the code (you probably want it in the same location. You may have to delete (move) the original directory before you do this, but right click -> svn check out. Select the same repository location you have been using and the location to put the code at and click 'OK'.

So that's how you start. Now you just modify the files and when done you can right click and 'commit' the changes. You can do this one file at a time or you can do it the entire project tree at a time. Periodically you will need to right click and 'update' the code to get the changes others have made. Generally I like to modify my code, update my code, build my code, test my code, and finally commit my changes. This prevents having 'broken' builds stored in the repository. SVN will automatically 'merge' changed code if possible. Too complex merging you will need to fix on your own. Merges happen when you update not when you commit.

Test this out with a local repository first to get used to the above on your own just to get a feel for it and then go from there. Hope this helps.

In layman's terms, a repository is like a central storage place. Updating is asking the librarian to give you the most up-to-date version of everything. Committing is passing on your local changes to the librarian. He notes it down, modifies the central storage, and whenever a next person wants an update, he passes on the most recent version, which now includes your modifications.

It's not only a way to keep a recent version of your project in one central place, it's also a giant undo/redo system, because you can look at previous versions of your project (the librarian keeps a database of all commits, he's good at that). And if you write down a message with each commit, you also get a change log for free. You can track down when a file was changed, and by who - and what exactly those changes were.


TortoiseSVN is a visual interface for svn. It integrates right into your Windows shell, so with a single right mouse button click you can access a menu with svn operations, such as the aforementioned update and commit actions. Other important actions are add and delete - the next commit will add or remove files from the repository when they are locally marked as such. Another action that you'll use occasionally is the show log action. It shows you what commits have been done that affected the currently selected file or folder.

Thanks a lot :D

Quote:Original post by Shadowwoelf
Alright so lets see if I understand this correctly.
I go and host my project on something like google svn.
Then I download all the files.

You download them by updating, yes. Though typically, you start with some files locally, and commit them to the repository - you'll have to start with some stuff, after all. :)

Quote:I update player.h and then commit the changes. My friend Bob didn't get the changes I made and changed something in player.h and committed the changes also.

He'll get a message that tells him that his player.h file is not up-to-date, so he has to update and merge the differences (sometimes this can be done automatically, sometimes it needs manual labor) before he can commit.

Quote:What if I changed player.h and commit the changes. Bob changes monster.h and commits the changes. Is this still one project or did it split off?

Still one project. However, as mentioned by nobodynews, it's a good idea to update and test before you commit your changes. You don't want to 'break the build'.