svn switch — Update working copy to a different URL.
The first variant of this subcommand (without the
            --relocate option) updates your working
            copy to point to a new URL—usually a URL that
            shares a common ancestor with your working copy, although
            not necessarily.  This is the Subversion way to move a
            working copy to a new branch.  If specified,
            PEGREV determines in which
            revision the target is first looked up.  See the section called “Traversing Branches” for an in-depth look
            at switching.
If --force is used, unversioned
            obstructing paths in the working copy do not automatically
            cause a failure if the switch attempts to add the same
            path.  If the obstructing path is the same type (file or
            directory) as the corresponding path in the repository, it
            becomes versioned but its contents are left untouched in
            the working copy.  This means that an obstructing
            directory's unversioned children may also obstruct and
            become versioned.  For files, any content differences
            between the obstruction and the repository are treated
            like a local modification to the working copy.  All
            properties from the repository are applied to the
            obstructing path.
As with most subcommands, you can limit the scope of
            the switch operation to a particular tree depth using the
            --depth option.  Alternatively, you can
            use the --set-depth option to set a new
            “sticky” working copy depth on the switch
            target.  Currently, the depth of a working copy directory
            can only be increased (telescoped more deeply); you cannot
            make a directory more shallow.
The --relocate option causes
            svn switch to do something different:
            it updates your working copy to point to the
            same repository directory, only at a different
            URL (typically because an administrator has moved the
            repository to another server, or to another URL on the
            same server).
--accept ARG --depth ARG --diff3-cmd CMD --force --ignore-externals --quiet (-q) --relocate --revision (-r) REV --set-depth ARG
If you're currently inside the directory
            vendors, which was branched to
            vendors-with-fix, and you'd like to
            switch your working copy to that branch:
$ svn switch http://svn.red-bean.com/repos/branches/vendors-with-fix . U myproj/foo.txt U myproj/bar.txt U myproj/baz.c U myproj/qux.c Updated to revision 31.
To switch back, just provide the URL to the location in the repository from which you originally checked out your working copy:
$ svn switch http://svn.red-bean.com/repos/trunk/vendors . U myproj/foo.txt U myproj/bar.txt U myproj/baz.c U myproj/qux.c Updated to revision 31.
You can switch just part of your working copy to a branch if you don't want to switch your entire working copy.
Sometimes an administrator might change the location
            (or apparent location) of your repository—in other
            words, the content of the repository doesn't change, but
            the repository's root URL does.  For example, the hostname
            may change, the URL scheme may change, or any part of the
            URL that leads to the repository itself may change.
            Rather than check out a new working copy, you can have the
            svn switch command
            “rewrite” your working copy's administrative
            metadata to refer to the new repository location.  If you
            use the --relocate option to svn
            switch, Subversion will contact the repository
            to validate the relocation request (looking for the
            repository at the new URL, of course), and then do this
            metadata rewriting.  No file contents will be changed as
            the result of this type of switch operation—this is
            a metadata-only modification to the working copy.
$ svn checkout file:///var/svn/repos test A test/a A test/b … $ mv repos newlocation $ cd test/ $ svn update svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///var/svn/repos' $ svn switch --relocate file:///var/svn/repos file:///tmp/newlocation . $ svn update At revision 3.
Be careful when using the
            --relocate option.  If you mistype the
            argument, you might end up creating nonsensical URLs
            within your working copy that render the whole workspace
            unusable and tricky to fix.  It's also important to
            understand exactly when one should or shouldn't use
            --relocate.  Here's the rule of
            thumb:
If the working copy needs to reflect a new directory within the repository, use just svn switch.
If the working copy still reflects the
                  same repository directory, but the location of the
                  repository itself has changed, use svn
                  switch with the --relocate option.