Differences

This shows you the differences between two versions of the page.

--- lirec:version_control_guide [2009-02-04 15:15] – davegriffiths
+++ lirec:version_control_guide [2009-02-04 15:54] – davegriffiths
@@ Line 13: / Line 13: @@
 The smaller the changes, and the more frequently you commit code, the less hassle you will cause for yourself and other people in the long run. This is an example day's work:
-  * First thing, updated to get the latest code
+  * First thing, update to get the latest code from the server
-  * Fixed a bug
+  * Build the new code, check it works
-  * Commit with a message explaining what you fixed
+  * Start working on a new feature as normal, edit - compile - test
-  * Start working on a new feature
-  * While doing that, found and fixed another bug
-  * Commit the files you changed to fix the bug (not the ones involved with the new feature)
   * Finish working on the new feature
-  * Commit with a message explaining what the new feature is
+  * Update and test the latest code on your machine
-  * Update the code again
+  * Commit your new code with a message explaining what the new feature is
   * Start working on the next feature
-And so on. 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).
+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=====
-I've set up the lirec svn repository with a dummy project called 'sandbox' that you can play with and break to your heart's content. This guide is written for the commandline version of svn, if you prefer buttons to press, read through this document anyway as the concepts are the same, and then have a look at [[http://tortoisesvn.tigris.org/|Tortoise SVN]]. [TODO - update this with a guide for using that.]
+I've set up the lirec svn repository with a dummy project called 'sandbox' that you can play with and break to your heart's content. This guide is written for the commandline version of svn, and heavily biased towards linux. If you prefer buttons to press, read through this document anyway as the concepts are the same, and then have a look at [[http://tortoisesvn.tigris.org/|Tortoise SVN]] or [[http://subclipse.tigris.org/|SubClipse]] if you use Eclipse or [[http://www.visualsvn.com/|VisualSVN]] if you use VisualStudio. [TODO - update this with a guide for using these systems.]
-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 in your .bashrc:
 <code>export EDITOR=vi</code>
@@ Line 70: / Line 67: @@
 This will merge everyone's changes (if any have been made) into your working directory. If there is a conflict (two people have changed the same line) it will emit an error message, and insert both lines into the source file in question with lots of <<<<<<<<< so it will be obvious what is going on.
+====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.
+<code>svn diff</code>
+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.