> Stefan Sperling <s...@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.