Getting started (for the Subversion unaware):

The O'Reilly Media book (free on line, but you can buy it too)
Good parts to read first: (What Is Subversion?, Fundamental Concepts )

A few SVN quotes:

ref: svnbook.red-bean.com, Chapter 4. Branching and Merging

For projects that have a large number of contributors, it's common for most people to have working copies of the trunk. Whenever someone needs to make a long-running change that is likely to disrupt the trunk, a standard procedure is to create a private branch and commit changes there until all the work is complete.

ref: What is a branch?

This is the basic concept of a branch-namely, a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time. A branch always begins life as a copy of something, and moves on from there, generating its own history (see Figure 4.1, Branches of development).

ref: What's the point of a branch?

You should remember two important lessons from this section. First, Subversion has no internal concept of a branch-it knows only how to make copies. When you copy a directory, the resultant directory is only a "branch" because you attach that meaning to it. You may think of the directory differently, or treat it differently, but to Subversion it's just an ordinary directory that happens to carry some extra historical information.

Second, because of this copy mechanism, Subversion's branches exist as normal filesystem directories in the repository. This is different from other version control systems, where branches are typically defined by adding extra-dimensional "labels" to collections of files. The location of your branch directory doesn't matter to Subversion. Most teams follow a convention of putting all branches into a /branches directory, but you're free to invent any policy you wish.

A few words about this project's tree managment approach:

The structure will be as follows:
/roombacomm
  ../trunk
     This is where the bleading edge development and believed to be fully working code for this project can be found. The structure should be usable as an SVN checkout  for the project source tree. In general the idea is that /trunk will be usable at all times. More deatils about the structure of the project in a seperate document.

  ../branches
     These branches are planed to be of one of two types: experemental or releases.
    Experemental branches:
     This is where long running development efforts will take place for the project. Each branch should follow the projects naming convention based on the type of branch. (See "SVN policies of this project" for details) In general, these branches should be considered "under development" or "experimental" and under the control of a developer. When the branch reaches a stability point, where the code implmentes the changes that are desired for the branch, has implemented any now needed testing code, and the code still passes all tests for the project then the branch is ready to be merged back into the trunk.
    Release branches are points of code development where it has been tested, prepaired, and packaged as a step forward for the project.

SVN policies of this project:

  1. all svn commits should have comments/log entries. (prefereably identifying each file that was altered and in laymen terms what was changed in that file)
  2. the keyword Id should be included in a comment in every file (do not forget to set the svn:keywords property on the file too.)
  3. /branches/release-N.N.N will be official releases of the project
  4. experemental branches are encouraged when any or all of the following is true:
    the development effort will take more than one commit to achieve
    the change is likely to break any backwards compatibility in the current/previous release
    automated testing failed, or the changes are not yet covered by automated testing
  5. code in compiled form should not be in SVN unless it is at least one of the following:
    an outside library that is included for simplicity/compatibility (best done with a Vendor Branch)
    it is in a packaged release for the project
  6. All new features developed must include automated testing code to validate the function.The tests should be constructed in accordance with the format and approach that the project is using for automated testing.

More general SVN references: