Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
lirec:version_control_guide [2009-02-04 14:54] – davegriffiths | lirec:version_control_guide [2009-02-04 15:55] – davegriffiths | ||
---|---|---|---|
Line 3: | Line 3: | ||
[[:Version control]] is a way to develop software in a scalable way. Even if you are the only person working on a project, it enables you to write code with more confidence, as you know you have every change tracked - no more wondering what you did which broke everything, as you can find out easily. You can also tag points in development for retrieval later on - it's a good idea to do this before working on big structural changes which could cause instability while you work on them. | [[:Version control]] is a way to develop software in a scalable way. Even if you are the only person working on a project, it enables you to write code with more confidence, as you know you have every change tracked - no more wondering what you did which broke everything, as you can find out easily. You can also tag points in development for retrieval later on - it's a good idea to do this before working on big structural changes which could cause instability while you work on them. | ||
- | Version control can be also be used in order to share development between groups of people, up to hundreds of developers. It takes care of merging all the changes together | + | Version control can be also be used in order to share development between groups of people, up to hundreds of developers. It takes care of merging all the changes together, which often worries people new to version control but it generally works well, and if it finds a confusing case (normally where two developers have changed the same line of code) it asks you to confirm what it's doing. |
=====Usage pattern===== | =====Usage pattern===== | ||
Line 9: | Line 9: | ||
Before we get into using svn, there are some basic usage patterns which are common to all revision control systems. You get the most out of version control if you make it part of your daily programming routine. | Before we get into using svn, there are some basic usage patterns which are common to all revision control systems. You get the most out of version control if you make it part of your daily programming routine. | ||
- | The general idea is that code lives on a remote server, and you keep a local copy of the source on your hard drive. You edit files as normal then ' | + | The general idea is that code lives on a remote server, and you keep a local copy of the source on your hard drive. You edit files and compile |
- | The smaller the changes | + | The smaller the changes, and the more frequently |
+ | * First thing, update to get the latest code from the server | ||
+ | * Build the new code, check it works | ||
+ | * Start working on a new feature as normal, edit - compile - test | ||
+ | * Finish working on the new feature | ||
+ | * Update and test the latest code on your machine | ||
+ | * Commit your new code with a message explaining what the new feature is | ||
+ | * Start working on the next feature | ||
+ | |||
+ | And so on. You only have to be strict about updating when there are other people actively working. The messages are important - they only need to be short one liners, but they need to explain why you changed what you did - but there is no need to explain what the changes were (you can tell this from the code, so it would be redundant information). | ||
=====SVN Basics===== | =====SVN Basics===== | ||
- | I've set up the lirec svn repository with a dummy project called sandbox that you can play with and break to your heart' | + | I've set up the lirec svn repository with a dummy project called |
- | Firstly svn likes to know what editor you like to use so it can launch it to ask you to input comments for your code commits. Put this in your .bashrc: | + | Firstly svn likes to know what editor you like to use so it can launch it to add comments for your code commits. Put this environment variable |
< | < | ||
- | Or the equivalent in windows [TODO]. | + | Or do the equivalent in windows [TODO]. |
====Getting the code==== | ====Getting the code==== | ||
Line 38: | Line 47: | ||
< | < | ||
- | This will pop up the editor you specified earlier. Add a nice informative message | + | This will pop up the editor you specified earlier. Add a nice informative message, save the file, and close the editor. If all is well, your change is now sent to the svn server. If, as sometimes happens to me, you realise at this point that you've forgotten something, close the editor without saving - svn will then ask you if you want to abort the commit. |
====Adding files==== | ====Adding files==== | ||
< | < | ||
- | Will add individual files, or recursively add files in a directory. | + | Will add individual files to the repository, or recursively add files in a directory. |
- | ====Directories, | + | ====Adding directories and moving |
< | < | ||
Line 56: | Line 65: | ||
< | < | ||
+ | |||
+ | This will merge everyone' | ||
+ | |||
+ | ====Diffing==== | ||
+ | |||
+ | It's often really useful to check where your copy of the code is different in comparison to the one on the server. This allows you to see what you've changed since you last committed code, and is really helpful when you need reassuring that you've changed what you think you've changed. | ||
+ | |||
+ | < | ||
+ | |||
+ | This will diff the entire sourcecode, and print out a list of changes it found. You can also specify individual files to diff too. There are utilities which read the output of this command and display it graphically if it's helpful, but you don't generally need them for small changes. | ||