--- On Tue, 12/6/11, kmra...@rockwellcollins.com <kmra...@rockwellcollins.com> wrote:
From: kmra...@rockwellcollins.com <kmra...@rockwellcollins.com> Subject: Re: New Server because of Crash To: users@subversion.apache.org Date: Tuesday, December 6, 2011, 7:30 PM > 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. -------- Thank you all for the help. It appears we lucked out though. Since this was built using flat files and dumps taken, we just had to migrate in the dumps (words of the person doing the restore). No commits were made between the time of the crash and the last backup so no data was lost doing it that way. Once the DNS was changed on the new server to match what it was on the old server, everything started working like nothing was different.
