Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

after a major server fault, svn repository was destroyed and my working version is most current one,

what is the way to recreate svn repository from my working version?

after installing svn on a new server and trying at my working copy

 svn switch NEW_SVN_PATH .

i get an error

 Repository UUID '1c604742-6b16-462b-86e4-cc8bce959242' doesn't match expected UUID '6df69aeb-a72c-450d-8102-24036a3855f7'
share|improve this question
add comment

4 Answers

up vote 2 down vote accepted

After initializing the new svn reporsitry

  1. on the client do an svn export of the current working directory to a different location
  2. from the exported locattion do a svn import to the new svn url
  3. now do a svn relocate to the new repositry created.

while this might work, i think instead of a relocate , a fresh checkout might be good

share|improve this answer
add comment

Had to deal with this. I use hosted subversion, and did a dump and then import. Their import process didn't transfer the UUID from the old repo to the new one so I got the same error as the OP. All the answers on the Stack Exchange sites only tell you how to deal with this by using "svnadmin setuuid", but that wasn't an option for me since I use a hosted service (and therefore svnadmin won't have access to the repository). I could have entered a ticket but didn't want to deal with the wait, so here is how i fixed it, by manually updating the UUID of my working copy:

Warning: only try this if you're certain the working copy and the repository you're re-pointing to are absolutely in sync. Not sure what will happen if they aren't.

The process is basically to replace old UUID with new UUID in the files named "entries" in the hidden svn folders (folders named .svn or _svn) of your working copy. Once that's done you can use TortoiseSVN's "relocate" to point the working dir to the new repository URL.

  1. In console window, cd to the root of your working folder.
  2. Run command to recursively remove the "read-only" attribute from the "entries" files: attrib -R entries /S
  3. Use a text editor's "replace in files" function to replace the old UUID with the new UUID. I used Visual Studio with the following settings: Look in: PATH_TO_WORKING_FOLDER_ROOT / Include sub-folders: checked / Look at these file types: entries
  4. Undo step #2: attrib +R entries /S
  5. "Relocate" working copy to new URL. I used TortoiseSVN: right-click working folder, TortoiseSVN->Relocate.

All step 5 does is replace the URL's in the "entries" files I think, so you might be able to do that manually if you wanted. Also possible with "svn" command line tool, but don't know the command off the top of my head.

share|improve this answer
    
This is intense. Is that really necessary? I'm just trying to figure it out since my provider apparently moved our repos and I get the same error. –  Till Sep 6 '11 at 17:28
add comment

You can set the UUID on an empty repository. Then import the files you do have. You will loose your history (it is not kept in the working copy). But, by setting the UUID to match your old repository you avoid the error message on the svn switch.

$ svnlook uuid /var/svn/repos
cf1b8d31-acb6-02dc-bc7c-16e92ce6dbec
$ svnadmin setuuid /var/svn/repos   # generate a new UUID
$ svnlook uuid /var/svn/repos
4c2c49fe-acc1-23dc-acbc-2b28ff0c9e6c
$ svnadmin setuuid /var/svn/repos 1c604742-6b16-462b-86e4-cc8bce959242  # restore the old UUID
$ svnlook uuid /var/svn/repos 1c604742-6b16-462b-86e4-cc8bce959242
share|improve this answer
    
my server version of svnadmin didn't have setuuid subcommand, guess it's one of newer commands. then i found a file db/uuid at repository, but after modifying the number in it, svn still complained that it's not the same repository –  Pavel K. Aug 18 '09 at 14:28
add comment

I had the same issue but since we use a hosted option, I couldn't svnadmin either.

This was an external I used in another project, and I did this to fix it:

  1. Backup all my local changes.
  2. rm -rf the directory (the external is checked into)
  3. remove svn:external (and commit that)
  4. svn up
  5. add the svn:external again
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.