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 which
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.
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).
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.
--revision (-r) REV --depth ARG --ignore-externals --force --accept ARG --quiet (-q) --diff3-cmd CMD --relocate FROM TO --username USER --password PASS --no-auth-cache --non-interactive --config-dir DIR
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.
And 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 just switch 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
“base location” of your repository—in
other words, the contents of the repository doesn't
change, but the main URL used to reach the root of the
repository does. For example, the hostname may change,
the URL scheme may change, or any part of the URL which leads to the
repository itself may change. Rather than check out a new working
copy, you can have the svn switch
command “rewrite” the beginnings of all the
URLs in your working copy. Use the
--relocate option to do the substitution.
No file contents are changed, nor is the repository
contacted. It's similar to running a Perl script over
your working copy .svn/ directories
which runs s/OldRoot/NewRoot/.
$ 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, then use just svn switch.
If the working copy still reflects the same repository directory, but the location of the repository itself has changed, then use svn switch --relocate.