Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revisionBoth sides next revision | ||
| lirec:version_control_guide [2009-02-04 16:08] – davegriffiths | lirec:version_control_guide [2009-02-04 16:16] – davegriffiths | ||
|---|---|---|---|
| Line 7: | Line 7: | ||
| It won't do all this magically though. Some usage patterns need to be followed by developers to make sure that they don't tread on each others toes. | It won't do all this magically though. Some usage patterns need to be followed by developers to make sure that they don't tread on each others toes. | ||
| - | =====Usage pattern===== | + | =====Revision control usage pattern===== |
| - | 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. | + | This usage pattern is 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 and compile 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 as normal then ' | ||
| Line 24: | Line 24: | ||
| 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). | 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). | ||
| + | |||
| + | You can also deal with more complex sequences of events: | ||
| + | |||
| + | * Start working on a new feature | ||
| + | * While doing this, you find a bug in another part of the code, and fix it | ||
| + | * Update and test the latest code on your machine | ||
| + | * Commit only the files you changed for the fix | ||
| + | * Finish working on the new feature | ||
| + | * Update and test the latest code on your machine | ||
| + | * Commit the new feature | ||
| + | |||
| + | The key point is that everyone is trying to make sure the version of the code on the server works as much of the time as possible. It's not the end of the world if the central version is broken, but it should be a priority to fix it, as it will hold people up from working. | ||
| =====SVN Basics===== | =====SVN Basics===== | ||
81.188.78.24