THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
All new development, whether new features or general improvements, should be integrated into the latest revision or the trunk. Once a new feature is implemented and integrated into the trunk it can then be decided which branches the new development should be applied to. There may be rare cases where a new development only applies to a particular branch but in general all new features go to the trunk first and disseminated from there. The important thing is that all changes go into the trunk first, then get merged into the release branch as needed, so no changes ever get dropped by mistake. Changes should be kept in sync at all times where possible and this is the responsbility of the release manager. So developers can focus on improvements in the trunk and the burden of merging will be the task of the release manager. New features or improvements should never originate from a branch
The responsibility of merging changes from the trunk to the various branches is the responsbility of the release manager for the branch in question. To be clear if you are committing changes to trunk do not merge your changes into any of the release branches.
...
so 2.0-RELEASE is a svn tag that is immutable, it is set once for a set of code, 2.0-STABLE becomes the bugfix branch for the 2.0-RELEASE...and people can track that -STABLE release for something they are assured to be solid and stable...2.1-SNAPSHOT would be development code, released periodically as per whatever rules govern development code release, as needed perhaps 
Notes from Garrett Rooney (an svn committer)
<jason_> any svn users who are familiar with the fly fishing technique?
<jason_> just looking for a little advice on working with branches
<chipig> fly fishing and branches?
<rooneg> i can give advice on working with branches, but i have no clue what you mean by "fly fishing technique" in that context
<jason_> http://cvsbook.red-bean.com/cvsbook.html#Going%20Out%20On%20A%20Limb%20(How%20To%20Work%20With%20Branches%20And%20Survive)
<jason_> rooneg, do you typically work on trunk and merge into the branch periodically or right away?
<rooneg> well, it depends what kind of branch you're talking about. is it a release branch? a maintenance branch? a feature branch?
<jason_> in this case a release branch
<jason_> well, we release from this branch
<rooneg> well, for subversion itself we use a technique like this. when we're ready to start preparing for a release we branch off of the trunk.
<jason_> http://svn.apache.org/viewcvs.cgi/maven/components/branches/maven-2.0.x/
<rooneg> any last minute modifications to the branch happen there (updating change lists, version numbers, etc), then we cut a release candidate.
<rooneg> at this point trunk development continues as usual
<rooneg> there is now a soak period, where the RC is tested. if bugs are found they are fixed on the trunk and then proposed for merging back to the branch.
<rooneg> when we've got enough fixes merged in that a new RC is justified we roll a new RC off the release branch
<rooneg> (rolling an RC means tagging it as well, FWIW)
--> jesse (n=jesse@216-161-72-109.omah.qwest.net) has joined #asf
<rooneg> eventualy one of our RCs is declared final, and we roll the final release with only a version number change relative to the last RC
<rooneg> the release branch (i.e. branches/1.2.x or branches/1.3.x) sticks around and we do basically the same thing for the next release.
<rooneg> the important thing is that all changes go into the trunk first, then get merged into the release branch as needed, so no changes ever get dropped by mistake
<jason_> cool, that's what i wanted to hear
<jason_> thx for the advice
<jason_> what's your name btw? just so i remember
<rooneg> no problem
<rooneg> Garrett Rooney 
More notes from Garrett and Paul Querna
<jason_> rooneg, do you use anything like that svnmerge.py script?
<jason_> is that a useful script, i just saw it in the svn contrib section
<rooneg> jason_: personally, no, i've never used it, but some svn developers do
<rooneg> it's really more useful for things like feature branches, where you intend to merge all changes from one branch into another.
<rooneg> so if i created a branch to work on a new feature, and i want to periodically merge the changes from trunk into it, to keep me up to date, svnmerge.py would help a lot
<rooneg> not sure how well it deals with cherry picking individual revisions though, like we do for release branches.
<jason_> are there many cases where changes would originate in a branch?
<jason_> does that ever happen much?
<chipig> not for release branches
<chipig> only if for whatever reason, the code in the release branch, doesn't exist in the trunk. IE with a depricated module.
<jason_> so from trunk to branch is the general rule, cool
<jason_> chipig: what's your name?
<rooneg> yeah, that's the general idea, it simplifies things, and ensures that you never accidentally fix a bug in an older version but not in a newer one
<rooneg> of course, development branches (like a branch to implement a particular feature) are diffeent, the whole point there is to implement some new feature, then merge it back to trunk later.
<quasi> jason_: there's this cool feature in irc clients - /whois
<jason_> well, you learn something new every day!
<jason_> well, i might guess it's mads toftum because your name has popped up on mailing lists but that result returned still isn't all that clear
<chipig> jason_: paul querna...
<jason_> chipig's came up with a full name
<quasi> jason_: correct
<jason_> cool, thanks for the advice. will go directly into maven development process doco.
Useful links
http://www.asterisk.org/developers/svn-branching-merging
http://www.reactos.org/wiki/index.php/Best_practices_for_working_with_branches
http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING
http://svn.collab.net/viewcvs/svn/trunk/contrib/client-side/
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/index.html