| | 2 | |
| | 3 | When working with any relevant amount of code, you'll soon notice it is a good idea to keep |
| | 4 | regular backups of working states in case things go wrong. Also, working on the same code in teams |
| | 5 | is near impossible without some kind of software to manage who changed what at what point in time. |
| | 6 | This is where tools like SVN come into play: They keep a record of all changes done to the code in |
| | 7 | a project and provide tools to add new changes, revert changes, keep different copies of the same |
| | 8 | code in parallel and much more. |
| | 9 | |
| | 10 | SVN uses a central server to store all this information. The typical workflow of a programmer in |
| | 11 | a project is hence as follows: |
| | 12 | * Download ("Check out" in SVN terminology) the newest version of the code |
| | 13 | * Make changes to the code |
| | 14 | * When done, upload your changes ("commit" in SVN terminology) to the central server ("repository") |
| | 15 | Ideally, SVN commits are done regularly over the course of a programming session and not just after |
| | 16 | hours and hours of coding. If you screw up in any way, you can always revert to the last working state. |
