Outline
- Version control systems
- Why do we use them?
- What happens if we don't?
- Which one is right for me?
- Version control vocabulary.
- How to organize your repository.
- Concurrent Versions System
- Pros and cons.
- Overview of basic commands.
- Branches, stickies, and other metadata.
- Things you'll probably use the most.
- Subversion
- Pros and Cons
- Basic commands in SVN are just like CVS.
- Things in SVN that make life easier.
- Working with revision numbers.
- Merging revisions.
- Patching
- Get the diff.
- Submit your patch somewhere.
- Applying and testing patches.
- Resources
- Revision Control Systems
- CVS
- SVN
Version control systems
Why do we use them?
We use version control systems to maintain our code (and our sanity). It is good practice to maintain your code in an orderly fashion, especially when you have a distributed development model (like Linux).
Version control helps us keep track of many things:
- Who did what
- When they did it
- Feature changes between major releases
- Dependencies
In general, the idea is to save time, reduce stress and increase productivity.
What happens if we don't?
Failure to use version control is a common source of screams, hair loss and headaches. If you don't keep a clean house, you will eventually lose things, step on something, or lose friends. Not keeping a clean code base can result in the same side effects:
- Team members get really mad at you.
- Loss of all your code.
- Dependency issues.
- Overwriting changes.
- Duplicated effort.
- Inability to go back to a working copy.
A project without version control is not very extensible and will most likely fall victim to one of the ailments listed above.
Which one is right for me?
The best tool for the job. Which system you pick should depend on what suits your needs, what your organization currently uses, etc. If you are joining a project midway, they should already have something – so naturally saying, "Let's use this instead!" might not be the most popular thing to say.
But, you should know that most projects use CVS or Subversion, which are variants of RCS. Unless you have a very good reason, you should probably use one of these because:
- they have decent documentation
- they will support all of the key version control needs you'll have
- they've been stress tested.
Version control vocabulary.
Some terms I'll throw around:
- trunk - I look at the trunk as the latest and greatest. It's the foundation of your project, the ongoing and evolving code that makes up the latest version of your application. It may not always be stable, but if your developers are smart they at least make sure the project runs when they check stuff in.
- tip - Same as trunk.
- branch - When developers need to make a lot of changes that would mess up other parts of the system and make the trunk unusable they make a branch. After they've made sure their branch works properly they merge it back into trunk.
- tag - Tags are typically used as 'snapshots'. For example, if you have a working version of your application on 2005-11-17, you would make a 20051117 tag and shove a copy of your trunk in there. That way, if you wanted to go back to that version you would always have it waiting for you. Some people like naming these based on version. It's up to you.
- diff - Diff is a utility in Linux/Unix that compares the differences between files. Run recursively you can get the total difference between multiple files and write them all to a single file.
- patch - A patch is basically a diff that can be applied to trunk/branch/tag to add or remove features. This is typically done via the patch utility.
How to organize your repository.
They key thing to remember is to give yourself room to grow. At the beginning of your project, chances are you won't have many documents and you won't see the immedeate need to create a multitude of directories that may seem confusing and extraneous.
But as your project grows, you'll eventually wish you has space for branches, tags, etc. – especially if you use CVS or any other version control system that doesn't let you easily move things around.
That said, you should consider a basic structure similar to this:
- root
- project
- branches
- 0.6-email-overhaul
- 0.6.1-security-email-fix
- 0.7-whatever-major-update.... and so on
- tags
- trunk
Once you get down in your app directory, all bets are off. You have the freedom to organize your application any way you want. How you do this may vary based on languages, frameworks, or any number of other factors. Here is an example of an application I wrote that had multiple languages:
- bouncer
- trunk
- README
- php
- python
- python-specific stuff, etc.
- docs
- documentation (phpDoc, etc.)
- sql
- database description (some .sql – probably a mysqldump, or something similar)
Try to just keep it as clean and simple as you can while still giving your project room to grow.
Concurrent Versions System
Pros and Cons
Overview of basic commands.
Branches, stickies, and other metadata.
Things you'll probably use the most.
Subversion
Pros and Cons
Basic commands in SVN are just like CVS.
Things in SVN that make life easier.
Working with revision numbers.
Merging revisions.
Patching
Get the diff.
Submit your patch somewhere.
Applying and testing patches.
Resources
Revision Control Systems
CVS
SVN
