This will be a three part series. Part 1 is aimed at the project leader. It explains why you need version control and how to set it up. Part 2 is aimed at the developer who will need to work with the version control, so covers how to use it. Part 3 is about conflicts and other important topics.
Introduction
You have version control. Either the team lead told you you use it, or you understand how useful it is. Or perhaps you just joined a sourceforge project and you need to get access to their repository. Whatever the reasons are, this post is looking at how to use SVN (in particular tortoise SVN) in your development.
A few terms
See: http://betterexplained.com/articles/a-visual-guide-to-version-control/ for a good summary.
I'm using the SVN terms as it will help later
- Repository: The 'shared directory' where the code lives, usually on a hosted server somewhere
- Import: take some brand new code & put it into the repository
- Check out: Get a fresh set of the code (usually the latest version) from the repository onto your local machine
- Update: Update the code on your local machine with the latest version in the repository
- Commit: Copy the code from your local machine into the repository
- Conflict: What happens when you try to commit some code and someone else has already made a modification to it
You will need
- A copy of Tortoise SVN ( http://tortoisesvn.net/)
- The URL of the SVN repository (the project lead will know this)
- A username & password (probably)
- Its worthwhile each developer having their own account, it encourages more responsible behaviour, as each commit has your name attached to it
The First Check Out
We need to get the latest code to work with, so this is where we start.
Get yourself a suitable directory. It doesn't need to be 100% empty, but it cannot have a directory with the same name as your project.
Right click on the base directory and SVN->Check out
to d:\work\project_name So we will get all the code we need in a new directory.
(PS. The HEAD revision, means the latest copy).
After we hit OK, the SVN will get the latest copy of the code, create the directory and put all the code in it.
Currently its just the readme, but we will add some code later. If you have a look on the hard disk, you will see the files added with a little green tick icon, which means they are up to date.
We now have the latest code.
After we hit OK, the SVN will get the latest copy of the code, create the directory and put all the code in it.
General Usage: Adding, Ignoring and Committing
OK, so we have a version control up, what next?
Write code of course...
<some time later>
What next?
Lets have a look at my directory right now:
I have added in a Visual C++ project and put in a bit of code. But life gets a little bit more complicated.
I don't want ALL of this stuff into the source control, mainly all the temp files and stuff, but especially the 100MB temp files which Visual Studio likes to generate.
As for knowing what to add & what not to add, this is down to the individual programming environment/language. But in my case, I want to ignore the following:
Very Important: Use the text box to add some comments to explain what you did. You want to know what other people have been doing to the code, so give the same feedback for them.
Most of the time it should work fine, unless you are working on old code. In which case you may need to do an update (see below).
Write code of course...
<some time later>
What next?
Lets have a look at my directory right now:
I don't want ALL of this stuff into the source control, mainly all the temp files and stuff, but especially the 100MB temp files which Visual Studio likes to generate.
As for knowing what to add & what not to add, this is down to the individual programming environment/language. But in my case, I want to ignore the following:
- Debug and Release folder
- The .NCB, the .SUO and the .user files
Therefore I right click on them and mark them to be ignored.
After that, I add in the files I want to add again by right clicking.
You notice how it is now marked with a + to show its been added.
However this does not mean its in the repository yet, that will not happen until we commit the directory to the server. We do this by selecting the directory and doing a commit.
This will show which files are changed (& will be sent to the repository), at the same time it will show up which files are unversioned (not added or ignored), for you to decide what to do with them. You can just right click & decide to add or ignore them.
(If you want to know what the changes are, just right click on the file & select 'compare')
Very Important: Use the text box to add some comments to explain what you did. You want to know what other people have been doing to the code, so give the same feedback for them.
General Usage: Viewing and Updating
What happens if the others are working on the project and you need to find out what is going on? Well, select the directory (or file), right click and select 'check log' which will give you the current history of the project:
Remember I said about adding the comments when you commit? Well you can see the comments listed here.
You can 'check for modifications' which will show you if your code if the most up to date, or if others have made changes to your code:
In this case, it seems that someone have updated one of the files, so what I can do is 'Update' to the latest copy of the code.
You can 'check for modifications' which will show you if your code if the most up to date, or if others have made changes to your code:
General Rules for use with Version Control
- Never check broken code into the version control, test it first
- Don't check in generated files (object code or similar), just the original source.
- It should be easy to regenerate the files from the source
- Make sure you are careful with what you add into the version control, don't add in junk.
- On one project, someone added a 200MB movie files into the version control. I was very unhappy with them
- Try to minimise the amount of non-text files which you add into your version control, as most systems don't handle them well & they take up a lot of space (compared with code)
- Some teams run version control for the code and then use a shared drive for art assets
- On a similar note, If you are going to add art assets in, only add in the final items in a form which is useable in the project
- Don't put in your raw photoshop files, just the final exported bitmap
- Keep the raw photoshop files in the shared drive
- It should be possible for someone to check out a complete your code from the version control system and build it without errors.
- Check it from time to time to make sure its still working
- There is a concept known as continuous integration http://en.wikipedia.org/wiki/Continuous_integration which automates this process
Conclusion
There are quite a few other items which I could cover (reverting, comparing and such), but these are the most common operations you need.
In part 3, I will cover dealing with the issues. In particular what happens when two people try to change the same piece for code at the same time?
Until then, Happy Coding,
Mark
In part 3, I will cover dealing with the issues. In particular what happens when two people try to change the same piece for code at the same time?
Until then, Happy Coding,
Mark
No comments:
Post a Comment