The svn switch command transforms an
existing working copy to reflect a different branch. While this
command isn't strictly necessary for working with branches, it
provides a nice shortcut. In our earlier example,
after creating your private branch, you checked out a fresh
working copy of the new repository directory. Instead, you can
simply ask Subversion to change your working copy of
/calc/trunk to mirror the new branch
$ cd calc $ svn info | grep URL URL: http://svn.example.com/repos/calc/trunk $ svn switch http://svn.example.com/repos/calc/branches/my-calc-branch U integer.c U button.c U Makefile Updated to revision 341. $ svn info | grep URL URL: http://svn.example.com/repos/calc/branches/my-calc-branch
After “switching” to the branch, your working copy is no different than what you would get from doing a fresh checkout of the directory. And it's usually more efficient to use this command, because often branches differ only by a small degree. The server sends only the minimal set of changes necessary to make your working copy reflect the branch directory.
The svn switch command also takes a
-r) option, so you
need not always move your working copy to the
HEAD of the branch.
Of course, most projects are more complicated than our
calc example, and contain multiple
subdirectories. Subversion users often follow a specific
algorithm when using branches:
Copy the project's entire “trunk” to a new branch directory.
Switch only part of the trunk working copy to mirror the branch.
In other words, if a user knows that the branch-work needs only to happen on a specific subdirectory, they use svn switch to move only that subdirectory to the branch. (Or sometimes users will switch just a single working file to the branch!) That way, they can continue to receive normal “trunk” updates to most of their working copy, but the switched portions will remain immune (unless someone commits a change to their branch). This feature adds a whole new dimension to the concept of a “mixed working copy”—not only can working copies contain a mixture of working revisions, but a mixture of repository locations as well.
If your working copy contains a number of switched subtrees from different repository locations, it continues to function as normal. When you update, you'll receive patches to each subtree as appropriate. When you commit, your local changes will still be applied as a single, atomic change to the repository.
Note that while it's okay for your working copy to reflect a mixture of repository locations, these locations must all be within the same repository. Subversion repositories aren't yet able to communicate with one another; that's a feature planned for the future. 
Because svn switch is essentially a variant of svn update, it shares the same behaviors; any local modifications in your working copy are preserved when new data arrives from the repository.
Have you ever found yourself making some complex edits
/trunk working copy) and
suddenly realized, “Hey, these changes ought to be in
their own branch?” A great technique to do this can
be summarized in two steps:
$ svn copy http://svn.example.com/repos/calc/trunk \ http://svn.example.com/repos/calc/branches/newbranch Committed revision 353. $ svn switch http://svn.example.com/repos/calc/branches/newbranch At revision 353.
The svn switch command, like svn update, preserves your local edits. At this point, your working copy is now a reflection of the newly created branch, and your next svn commit invocation will send your changes there.