<p>My motivation for trying out git-svn is the effortless merging and branching. Then I noticed that man git-svn(1) says: </p>

<blockquote>
  <p>Running git-merge or git-pull is NOT recommended on a branch you plan
  to dcommit from. Subversion does not represent merges in any
  reasonable or useful fashion; so users using Subversion cannot see any
  merges you've made. Furthermore, if you merge or pull from a git
  branch that is a mirror of an SVN branch, dcommit may commit to the
  wrong branch.</p>
</blockquote>

<p>Does this mean I cannot create a local branch from svn/trunk (or a branch), hack away, merge back into svn/trunk, then dcommit? I understand that svn users will see the same mess that merges in svn pre 1.5.x have always been, but are there any other drawbacks? That last sentence worries me, too. Do people routinely do these kinds of things?</p>

Creating local branches is definitely possible with git-svn. As long as you're just using local branches for yourself, and not trying to use git to merge between upstream svn branches, you should be fine.
I have a "master" branch that I use to track the svn server. This is the only branch that I dcommit from. If I'm doing some work, I create a topic branch and work away on it. When I want to commit it, I do the following:
Commit everything to the topic branch
git svn rebase
(resolve any conflicts between your work and svn)
git checkout master
git svn rebase
(this makes the next step a fast-forward merge, see Aaron's comments below)
git merge topic_branch
resolve any merge conflicts
(there shouldn't be any at this point)
git svn dcommit
I also have another situation where I need to maintain some local changes (for debugging) that should never be pushed up to svn. For that, I have the above master branch but also a branch called "work" where I normally do work. Topic branches are branched off work. When I want to commit work there, I checkout master and use cherry-pick to pick the commits from the work branch that I want to commit to svn. This is because I want to avoid committing the three local change commits. Then, I dcommit from the master branch and rebase everything.
It is worthwhile running
```
git svn dcommit -n
```
first to make sure that you are about to commit exactly what you intend to commit. Unlike git, rewriting history in svn is hard!
I feel that there must be a better way to merge the change on a topic branch while skipping those local change commits than using cherry-pick, so if anybody has any ideas they would be welcome.