This section is from the "Version Control with Subversion" book, by Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato. Also available from Amazon: Version Control with Subversion.
There are some standard, recommended ways to organize a
repository. Most people create a trunk
directory to hold the “main line” of development,
a branches
directory to contain branch
copies, and a tags
directory to contain
tag copies. If a repository holds only one project, then
often people create these top-level directories:
/trunk /branches /tags
If a repository contains multiple projects, admins typically index their layout by project (see the section called “Planning Your Repository Organization” to read more about “project roots”):
/paint/trunk /paint/branches /paint/tags /calc/trunk /calc/branches /calc/tags
Of course, you're free to ignore these common layouts. You can create any sort of variation, whatever works best for you or your team. Remember that whatever you choose, it's not a permanent commitment. You can reorganize your repository at any time. Because branches and tags are ordinary directories, the svn move command can move or rename them however you wish. Switching from one layout to another is just a matter of issuing a series of server-side moves; if you don't like the way things are organized in the repository, just juggle the directories around.
Remember, though, that while moving directories may be easy to do, you need to be considerate of your users as well. Your juggling can be disorienting to users with existing working copies. If a user has a working copy of a particular repository directory, your svn move operation might remove the path from the latest revision. When the user next runs svn update, she will be told that her working copy represents a path that no longer exists, and the user will be forced to svn switch to the new location.