> 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.
Forgot to add that ALL users will need to re-create their
working copies if the UUID changes. In my opinion this
is probably best if you know transactions occurred
since the last svn dumpfile was generated.
Kevin R.
Received on 2011-12-06 20:30:49 CET