Tagging and branching are done by copying. Copying is extremely cheap in subversion.

Experienced subversion users tend to start a project repository with three top-level directories: trunk, branches and tags. Within trunk is the main codebase. Within branched and tags are directories which are all the branches and tags made over time. So svn://svn.server/branches/2009dec is how the 2009dec branch is referenced whilst svn://svn.server/trunk is how the unbranched code is referenced. This means making a new branch is as simple as svn cp svn://svn.server/trunk svn://svn.server/branches/2010jan (and it will ask you for a comment).

As for versions, no, individual files do not get versioned: the whole repository gets versioned. Yes, it feels wierd for a while if all you're used to is the way CVS (and many others) do it, but it solves some fundamental problems and makes a lot of other things easier.

One of the biggest benefits is that a delta can include all changes in fifteen files. The idea is when you do changes that all depend on each other, you check them as one change, no matter how many files are touched. Subversion deliberately makes it difficult (not impossible, but difficult) to get a partial of such a delta out of the repository which reduces problems of fishing out a partial, and thus broken, change.

The other big benefit is that it can track renames and other file movements. CVS has never done that well, because the file history is associated to a file, not the repository. Other version-per-file source control systems also have this problem.

It also means the history is attached to the repository, not the files. You get one history log, not a disparate mess of one per file. It does, however, filter out unrelated changes, so it will return a full log from svn://svn.server/ but will show only the changes to the indicated directory if you look at svn://svn.server/branches/2009dec/

Once you get used to the repository being versioned, you won't miss individual versioning on the files.

Wade.