Subversion admin - moving repository around...
crosspost from http://rextang.net/blogs/work/
Some tips while moving / copying Subversion repository around...
It happened to my case that I have to move one project repository from my subversion server back to other office. here is the sequences of processes, just for reference.
(server-side operations...)
1. dump (all the) revisions.
using dump command to dump all the revisions or revisions one needs to a plan dump file.
[home]$ svnadmin dump /repo/root/path > repo-dump-file
dump command usage:
[home]$ svnadmin dump --help
dump: usage: svnadmin dump REPOS_PATH [-r LOWER[:UPPER]] [--incremental]
Dump the contents of filesystem to stdout in a 'dumpfile'
portable format, sending feedback to stderr. Dump revisions
LOWER rev through UPPER rev. If no revisions are given, dump all
revision trees. If only LOWER is given, dump that one revision tree.
If --incremental is passed, then the first revision dumped will be
a diff against the previous revision, instead of the usual fulltext.
Valid options:
-r [--revision] arg : specify revision number ARG (or X:Y range)
--incremental : dump incrementally
--deltas : use deltas in dump output
-q [--quiet] : no progress (only errors) to stderr
2. copy dump file to other subversion server for restore. (remember to zip it before putting it to a url for download or ftp, it's plan text and normally got 60% compression rate).
3. on destination subversion server, first create a new repository for this restore (svn book page 68).
[home]$ svnadmin create /path/to/repos
svnadmin create usage:
[home]$ svnadmin create --help
create: usage: svnadmin create REPOS_PATH
Create a new, empty repository at REPOS_PATH.
Valid options:
--bdb-txn-nosync : disable fsync at transaction commit [Berkeley DB]
--bdb-log-keep : disable automatic log file removal [Berkeley DB]
--config-dir arg : read user configuration files from directory ARG
--fs-type arg : type of repository: 'fsfs' (default) or 'bdb'
4. now load back the dump file, be SURE to include "--force-uuid" parameter.
[home]$ svnadmin load --force-uuid /new/repo/path < repo-dump-file
svnadmin load usage:
[home]$ svnadmin load --help
load: usage: svnadmin load REPOS_PATH
Read a 'dumpfile'-formatted stream from stdin, committing
new revisions into the repository's filesystem. If the repository
was previously empty, its UUID will, by default, be changed to the
one specified in the stream. Progress feedback is sent to stdout.
Valid options:
-q [--quiet] : no progress (only errors) to stderr
--ignore-uuid : ignore any repos UUID found in the stream
--force-uuid : set repos UUID to that found in stream, if any
--use-pre-commit-hook : call pre-commit hook before committing revisions
--use-post-commit-hook : call post-commit hook after committing revisions
--parent-dir arg : load at specified directory in repository
5. set proper svn.access and svn.passwd file to protect new repository, if any.
This complete server-side operations.
the reason of using "--force-uuid" at "svnadmin load" command is that while creating new repository at new server place, it will generate a new uuid for the generated repository. if load the dump file without forcing the uuid of the dump stream, the new repository will contain new uuid and client operation will fail by using "svn switch --relocate" operation.
so, after server-side opeations, it's now easy to switch one's working copy.
at client-side's pc containing the working copy of original repository, if using command line, enter following command:
svn switch --relocate http://my.original.repository.com/proj1/trunk http://my.new.repository.com/proj1/trunk
svn switch usage:
[home]$ svn switch --help
switch (sw): Update the working copy to a different URL.
usage: 1. switch URL [PATH]
2. switch --relocate FROM TO [PATH...]
1. Update the working copy to mirror a new URL within the repository.
This behaviour is similar to 'svn update', and is the way to
move a working copy to a branch or tag within the same repository.
2. Rewrite working copy URL metadata to reflect a syntactic change only.
This is used when repository's root URL changes (such as a scheme
or hostname change) but your working copy still reflects the same
directory within the same repository.
Valid options:
-r [--revision] arg : ARG (some commands also take ARG1:ARG2 range)
A revision argument can be one of:
NUMBER revision number
"{" DATE "}" revision at start of the date
"HEAD" latest in repository
"BASE" base rev of item's working copy
"COMMITTED" last commit at or before BASE
"PREV" revision just before COMMITTED
-N [--non-recursive] : operate on single directory only
-q [--quiet] : print as little as possible
--diff3-cmd arg : use ARG as merge command
--relocate : relocate via URL-rewriting
--username arg : specify a username ARG
--password arg : specify a password ARG
--no-auth-cache : do not cache authentication tokens
--non-interactive : do no interactive prompting
--config-dir arg : read user configuration files from directory ARG
or just using TortoiseSVN to let it do that for you:
if one has new login credentials on new repository, it will ask again for the login.
most of processes are just like what described in svn book, the only conclusion is that be sure to include "--force-uuid" while "svnadmin load" operation to prevent client "svn switch --relocate" operation error because of different uuid between original and new repositories.
Technorati Tags: admin , subversion