1

I needed to deleted some bad versions that were checked in to my SVN, so I followed the instructions that I got from another StackOverflow question here: https://superuser.com/questions/95432/want-to-delete-revisions-from-my-svn-repository

 svnadmin create newrepo
 svnadmin dump -r 0:1231 repo | svnadmin load newrepo
 mv repo oldrepo
 mv newrepo repo

It seemed to work great at first, but then I noticed that when we started checking files in again it was doing some really weird things. It was ignoring our commit comments and instead using the previous comments from the original check in at that revision. In fact, the date was the original date of that revision, not the current date of check in, and the files listed were all the original files from the first check in. When we do a Compare To Previous Revision, it shows a message that no changes were found, and it does have our actual changes saved.

So what it looks like to me is that there is a log file or some kind of directory file somewhere that SVN uses to track commits that didn't get cleaned out with my dump and mv. Anybody know where I can go to clean up this file so that I can have the right commit information logged this time around?

Community
  • 1
  • 1
user2480201
  • 131
  • 2
  • 12

1 Answers1

0

Ok! So I figured out what the problem was after stumbling across this StackOverflow:

Roll back or revert entire svn repository to an older revision

One of the replies talks about the path/db/current. The whole reply by fuenfundachtzig says,

If you have access to the SVN server, you can just edit path/db/current, put the old revision number you want to revert to (here: 24) there, and remove no longer needed revision files (i.e. 25, 26, 27, 28) from path/db/revs/0/. At least this worked for me today, after I had accidentally removed a directory in the repository.

This gave me a clue as to what some of those files in the repository folders meant. Browsing around, I realized that my revision number and actual revisions were all correct. I explored path/db/revprops and discovered that my real commit logs WERE being saved. So everything looked right and that led me to think that maybe there was some kind of log cache or something that the tortoise svn side of it was pulling from. That led me to this article:

http://tortoisesvn.net/logcacheuuids.html

which made me realize that the uuids on the oldrepo and newrepo were the same. I created a new uuid according to the above article's directions and the problem was solved!

Hope this helps someone else. I'm not sure if the mistake was that I was missing some flag when I did my initial dump or load of the oldrepo as to why my uuid was the same or if it was just a step that I didn't realize I had to do to update my uuid, but once that was done everything was hunky dory.

Community
  • 1
  • 1
user2480201
  • 131
  • 2
  • 12