tags:

views:

787

answers:

3

This afternoon, upon noticing a broken build and the fact that some files looked like very old versions (about 2 weeks old), I checked the svn log. Apparently just this afternoon, 1 of the developers did an "svn copy" of a directory from an older revision to the same directory. Thus it appears that the latest version "i.e. head" of all the files in that directory are really old, and all the history "i.e. log" is even older.

However, I think I can recover by using another "svn copy" (i.e. the disease is the cure). What I am considering doing is finding the revision where the bad "svn copy" was done (say rev 1234) , subtracting 1 (1233) and doing:

svn copy -r 1233 file://path/to/messed/up/dir file://path/to/messed/up/dir

That should restore the latest version, as well as get back all my history. Am I right about this?

A: 

Probably, but make a backup first.

Actually, I'm left wondering why you don't have a daily backup that you can just restore from already... Your SVN repository is surely important enough for that?

DannySmurf
In theory, the SVN repository itself is the backup for things like this. Backing up your repository itself should only be due to "external" disasters (hardware, rm -rf *, floods, etc.).
Brian Knoblauch
I'd say a blast of the current source tree (plus other stupidity that's been overlooked that was committed at the same time) is at the same level as a rm -rf type disaster. The repository is currently in an unknown state. The point of a backup is to blanket-return a system to a known, working state.
DannySmurf
+1  A: 

This copy command doesn't work for two reasons:

  1. as the target directory already exists, svn treats the copying request as copying into the target directory; you can't overwrite with cp. So this would create up/dir/dir. When the HEAD version of dir was created, there must have been a remove operation first, also.
  2. it is a request to copy the version 1233 of the HEAD object up/dir.However, the dir object in HEAD did not have a revision 1233; the object with the same path that did have such a revision was removed.

To fix this, you need to

  1. remove the current dir object:

    svn rm file:///path/to/messed/up/dir
    
  2. Copy using "peg revisions"

    svn cp file:///path/to/messed/up/dir@1233 file:///path/to/messed/up
    
Martin v. Löwis
+7  A: 

According to the SVN book,

svn merge -c -1234

should do the trick.

There's a whole section about this in the book.

The verbose explanation: -c -1234 translates into -r 1234:1233, which reverts the change from revision 1234.

Palmin