Branches are handy for developing larger features (especially if you
temporarily break muse and then fix it again). You might want to ask
why you shouldn't simply develop in your local working copy, and then
commit a huge chunk. Well, this has multiple reasons:
  o with branches, you'll have a history, because there are many small
    commits. this makes bisecting for finding a bug possible.
  o when you develop your feature publicly, others can check out half-done
    versions, and already test the one half. they also could fix bugs.
  o another advantage of keeping it public is: others can see whether you
    may exclude some use case and inform you about that in time. otherwise
    you'd spend lots of work in a design which was obsolete from the
    beginning.
  o and it shows that there's something going on :)

also, branching makes "feature freezes" easier, for release planning.

General note: ^/trunk means [url of the repo]/trunk. when you're inside
a working copy, svn understands the ^/trunk notation.
i assume you're inside some working copy

whenever merging, make sure you're in the correct directory!

CREATING A BRANCH
  the following command creates a branch called yourbranch in the branches
  directory, which is built upon the current (NOT the checked out!) trunk
  revision:

  svn copy ^/trunk ^/branches/yourbranch

  svn copy does a "light copy", that is, as long as you don't change files,
  they don't occupy any disk space.

USING THE BRANCH
  you might want to checkout every branch relevant to you into another local
  copy. believe me, it makes life easier. alternatively, svn switch is your
  friend.
  just develop inside the working copy, then commit.

MERGING WITH THE PARENT BRANCH (in my example: the trunk)
  from time to time, you want to update your branch to represent the
  current trunk plus your changes (and not an ancient trunk plus your
  changes). to be safe, only merge with the parent branch, and only
  merge in one direction (usually from trunk into your branch), unless
  you know what you're doing. if you're reading and not skimming this,
  you're probably NOT knowing. svn help and google are your friends.

  be in your branch'es working directory root (the dir which is containing
  all the files/dirs also trunk (the parent) is containing as well.

  svn merge ^/trunk --accept postpone

  does the job for you. there might be conflicts, when both in your branch
  and in trunk some file has been changes at a similar location. svn by
  default asks you what to do then, which is annoying. --accept postpone
  turns this off, and gives you a summary at the end of the merge.
  
  If There Were Conflicts:
    if any file in "svn status"'s output has a C in front of it, there are
    conflicts. open the file in your editor, and look for markers like
    "<<<<<", "=====" and ">>>>>". these show what code is in the trunk
    (between <<<< and ====), and what code is in your branch (between
    ==== and >>>>) (or vice versa. svn tells you).
    you have to make it work again and save the file.
    
    with "svn resolved FILENAME" or "svn resolved -R some/directory" you
    mark the conflicts for FILENAME or all files below some/directory as
    solved.
  
  Another word about conflicts: there may be conflicts, even if svn doesn't
  note them. ALWAYS recompile the merged code and test it.
  
  if done, you can commit the merge normally using "svn commit"
  
PUTTING YOUR WORK BACK INTO THE PARENT BRANCH (in my example: trunk)
  do a final merge from your parent branch into your branch. compile and
  test.
  then there are several ways to proceed:
    o use svn merge --reintegrate, which doesn't work with the old repo
      version muse is using :(
    o go into the trunk (or the parent branch'es directory), and issue
         svn merge ^/branches/yourbranch --accept theirs-full
      the problem with the merge is, that every previous merge from trunk
      into your branch will be applied a second time, which doesn't work.
      --accept theirs-full will basically use the files in your branch.
      you might want to verify with diff:
         diff -R /path/to/local/trunk /path/to/local/yourbranch
      there should be no differences.
      
      commit that to trunk: svn commit

      then, "fake-merge" trunk into your branch again. otherwise, with the
      next merge from trunk into your branch, we would have the duplicate
      changes problem again. if you're _SURE_ that you aren't using the
      branch any more, you can leave this step out.

      svn merge ^/trunk ^/branches/yourbranch --record-only
      svn commit
     

  this solution is a bit hackish :( but it works


NOTES FOR RELEASE BRANCHES
  after creating the release branch, ALL commits which are fixing bugs
  must go into the release branch. ALL commits which are adding features
  must go into trunk or other branches.
  the team should focus on fixing bugs in the release branch.
  to get the fixes into the trunk, from time to time run:

  svn merge ^/branches/releasebranch ^/trunk
  svn commit (in trunk's local copy)
  
  when releasing the release branch, merge it into the trunk a last time,
  and then never touch the release branch again.
  for the next release, create a new one.

TAGGING
  when there's any reason for tagging a revision, simply do
  svn copy ^/whatever ^/tags/yourtagname
  read the svn manual for details

GETTING HELP:
  svn help <command> (usage notes, short explanations)
  google (everything)
  the svn book (->google) (long explanations)