On Oct 14, 2009, at 13:54, Adam Funk wrote:
> At the moment I back up my repository using this script from a cron
> job:
>
> #v+
> DSTR=`date +%Y%m%d-%H%M` # e.g. 20011230-0305
> REPOS='/usr/local/svn/repository'
> DUMP_NAME="bunsen-svn-${DSTR}.dump"
>
> pushd /var/scratch/backups
> svnadmin dump -q ${REPOS} >${DUMP_NAME}
> popd
> #v-
>
> and I later copy the back-up file somewhere safe. The repository is
> almost at version 700 now, and I never need to look back more than a
> couple of revisions, so I'd be willing to lose a lot of history in
> order to reduce the size of the back-up file, but I want to check that
> I understand the -r option correctly. If I change the dump command to
>
> svnadmin dump -q -r 600:HEAD ${REPOS} >${DUMP_NAME}
>
> and I need to restore the repository from the back-up, does that mean
> I could do all of "svn up -r 600", "svn up -r 601", ..., "svn up"
> successfully from it? For example, would it keep files that had been
> checked in at r300 and not modified since then?
Yes, the backup will preserve anything that exists between revisions
600 and HEAD, regardless when those items were initially created. But
it will not keep the history of any changes (the diffs, or the log
messages) of events that occurred before 600.
I strongly recommend you continue to back up your entire repository,
and not attempt to cut out revisions to save space. Cutting out
revisions does not always save space; sometimes it increases your disk
space requirement.
In addition, if you were to restore this partial dump into a new
repository, it would be a totally different repository than before.
You would have to give it a new UUID, and would therefore have to
delete and re-checkout any working copies you had and manually move
over any uncommitted changes you still had in them. It would not be a
seamless operation. I'm sure that, if you're in a situation where
you've just had to restore your repository, due to hard drive
malfunction or whatever, you'll already have enough to deal with
without also having to deal with recreating all your working copies.
Old revisions never change. (Though old revision properties might
change, if you allow it with a pre-revprop-change hook.) So consider
creating a dumpfile of the first 600 revisions and burning them to a
CD or DVD. Then your regular backup routine can still just back up
revision 600 through HEAD, and you can still restore the entire
history by first loading the first 600 revisions from the CD or DVD,
then loading the current backup. You may or may not want to create
your 600-through-HEAD dump using the --incremental switch.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2407775
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-15 06:45:21 CEST