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 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).
--acceptARG
--depthARG
--diff3-cmdCMD
--force --ignore-externals --quiet (-q) --relocate --revision (-r)REV
--set-depthARG
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.