Redbook is great. As is Eric Sink's Howto (good for all version control systems).
But, very briefly, set yourself up with these top level directories, even if you're a single developer, and things will start to make sense:
- trunk - The main code branch, normal work goes in here
- branches - Make new branches underneath here, good for experiments, stabilizing & maintaining a release version
- tags - Make new branches into here then leave them alone, lets you give a name specific versions of your project (eg, release versions)
An a brief description of those terms:
- Branch - Noun. a container for a set of changes (just a folder). Verb. Creating a new container from an existing one (this is the only way of creating branches other than trunk, all branches ultimately come from trunk).
- Tag - A branch that doesn't change.
- Merge (Branches) - Verb. The act of copying a set of changes from one Branch to another. Involves merging the changes made to each file in the branch.
- Merge (Files) - Verb. The act of applying the changes made to one file in a branch to the equivalent file in another branch.
- Lock - Noun. Mechanism to prevent other people from making changes to the same file on the same branch. Good for files that can't be merged, like images. Doesn't work across branches. Verb. The act of using that mechanism.
- Patch - Noun. A text file containing a set of changes in a special format. Used for sending or receiving changes from people who don't have access to your repository. Verb. The act of creating or applying a patch. Also, sometimes the act of making a fix to a specific version of the code.
And now (as it's lunch) a story as an example as how some of these can be used:
A developer takes all the code for their project and dumps it into SVN. They then create a 'trunk' folder, and move all the code into this folder, thus creating the trunk branch.
The dev wants to try something, so copies the trunk branch into /branches/experiment1. This experiment branch is checked out to its own folder and worked on a little bit on the side.
Some normal development changes are made to trunk as well.
The developer decides that the experimental changes were good, and merges the changes from the experimental branch back into trunk. This kind of merge is called a reintegration. The experimental branch in now deleted, since it's finished with. If the experiment didn't go well, the branch could have just been deleted without polluting trunk at all.
Developer wants to release the project, so copies the latest trunk into tags as /tags/v1.0
The project is built from this tag and released to the public.
Development continues on the trunk branch.
A bug is found in v1.0, developer branches the tag to /branches/fix1.0 and makes a fix, then branches again to /tags/v1.1. The release build is made from /tags/v1.1.
The changes made in /branches/fix1.0 are merged into trunk, so that they're not lost, and fix1.0 is deleted as it's now finished with.