[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: New Server because of Crash

From: <kmradke_at_rockwellcollins.com>
Date: Tue, 6 Dec 2011 13:18:04 -0600

Stefan Sperling <stsp_at_elego.de> wrote on 12/06/2011 12:45:36 PM:
> > How would I get the uuid's. We have the dump, but I believe that
> is it. Can the uuids be obtained from them, would it be simpler to
> just have everyone do a new checkout?
>
> The UUID is somewhere near the top of the dump file in a line that
> starts with "UUID:".
>
> If you load into a repository which was freshly created with
> 'svnadmin create' the 'svnadmin load' process will change the UUID
> of this repository to match the one found in the dump.

You may however want to force new uuids if there were any committed
changes that were not in the last dump. This would force users
to create new working copies, because their old ones may be "newer"
than the last dump that you restored from causing problems.

My process (assuming changes were commited to the repository
after the dumpfile was created and you do not have incremental
dump files):

1) Rebuild server
2) Create new empty repository
3) Load dumpfile with a *new* UUID
4) Find the most up-to-date working copy and compare with a
   checkout of the new repository
5) Manually apply any changes identified in step #4 and
   commit them to the new repository

And to ensure steps #4-5 are not needed in the future:

6) Implement incremental dumpfiles of each transaction as they
   occur to secondary storage area
and/or
7) Replicate repository to secondary storage/server

Unless you have other backups, hooks scripts and file
locks will not be restored in the svndump file so
they will need to be manually re-created.

Kevin R.
Received on 2011-12-06 20:18:40 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.