I'd been using Concurrent Versioning System, aka CVS, for some time to manage a previous software development project I had managed. It worked OK to do basic code management, backups and versioning control. However, the limits of CVS were apparent if you even tried to do anything beyond the basics. Don't get me wrong, I don't mean to trash CVS - the issues I ran into could have been my own lack of knowledge on how to use it!
I was introduced to Subversion through Nexista, which was hosted at Tigris. Tigris also hosted Subversion, so I gave it a shot. Seemed to fill the shoes of CVS perfectly well, the commands were similar so it was easy to learn. Hadn't had any reason to try anything fancy, until now.
We rebuilt several of our servers so first I had to move the repository from one machine to another. We actually moved the entire filesystem, so the repository came with it. No problem.
Next, I created a branch. Branches are like alternate lines of software development. You can mix and match revisions along the branch developments in a very simple and straightforward manner. Best of all, branches do not complicate or overburden the repository, so if you have a reason to create a branch, go for it, create a subversion repository branch.
To keep learning about SVN, I decided to move the repository to another part of the filesystem. To do so, I used the commands outlined in the above link. Then I decided to merge to repositories, and rearrange the projects within the repository. Guess what, it all worked! And it all made sense! The free online book helps out immensely, so I recommend going directly to that source:
Just realized something about tags and branches. Since I am the only one developing software, a tag is all I need at this point. It seems like branches are better for concurrent versioning, where multiple people are working on different checkouts.
External Links about Subversion