CODEWITHSUNDEEP
svntortoisesvnvisualsvn-server
Vinix Wu
Vinix Wu

Reputation: 31

Is it possible to recover certain SVN revision by reverse merge?

I have TortoiseSVN 1.8.7 + VisualSVN Server 2.7.7 installed on my PC (Windows Server 2012). Recently my colleague told me when he try to update, "The XML response contains invalid XML" error appeared after the dialog listed several updated files. When he update again, the working copy is locked and need cleanup.

I'm using the same repository as my colleague, but I can update and commit without problem.

After investigation, I found disk error in Event Viewer, and when I opened the log, I can not see log earlier than 6291. I tried to open the file "project\db\rev\6290", and after 10~15 sec., the content is empty, and more disk error is appeared in Event Viewer. I copied all files with robocopy to another disk, only the file above is failed.

I thought these revision files are like diff files, so maybe I can use working copy(currently r6295) and project\db\6291~6295 to "reverse merge" to 6290? Is it possible?

Upvotes: 3

Views: 11710

Answers (4)

womp
womp

Reputation: 116987

While running Kapersky Endpoint Security 10.0 on my company laptop, I encountered this error repeatedly within a minute or so of initiating a checkout of a large source branch.

Temporarily disabling the Kapersky protection solved the issue for me.

Upvotes: 3

Lina Beb
Lina Beb

Reputation: 1

I have encounter this problem just now I manage to figure it out. let me share what I did.

1) choose your Workspace folder and right click choose TortoiseSVN>>Settings

2) in setting window choose Log Caching >> Cached Repositories

3)make sure your svn directories is correct. the most important thing is you just need to click at your Repository URL and click on UPDATE button..once finish just clean up your workspace by right click TortoiseSVN>>CleanUp.

all the best..

Upvotes: 0

Vinix Wu
Vinix Wu

Reputation: 31

The file \db\revprops\6290 is still intact so I can see the log I typed. It reminds me that only 1 file is modified in that revision.

So I performed the following steps:

  1. Move files of revision 6290~6295 to another location from \db\revprops and \db\revs for backup.
  2. Modify \current and set latest revision to 6289.
  3. Modify the file which was originally modified in r6290 again and commit, so there will be new files 6290 in both \db\revprops and \db\revs.
  4. Move files backed up in step 1 back to \db\revprops and \db\revs. The file \db\revprops\6290 is overwritten so the original commit date is recovered as well.
  5. Modify \current and set latest revision back to 6295.

Now my colleague can update normally and I can see all revision logs if I use Repository Explorer and enter the URL(begins with https) of VisualSVN Server.

I could not see log earlier than 6291 in my working copy. So I checked out to another dir and replaced .svn dir. It still displayed r6291~6295 only at the beginning. But it displayed normally when I tried again after several minutes. Looked like old data is cached somewhere.

So it's solved. But these steps are only useful if you remember what is modified in broken revisions.

Upvotes: 0

bahrep
bahrep

Reputation: 30662

Reverse merge won't help here.

At first, it makes sense to determine the root cause of the error your colleague gets. You say that you don't get the error, so it brings us to the following questions:

  • Is his working copy broken? Run svn cleanup against the working copy and see whether the error persists. It also makes sense to attempt reproducing the error with a clean working copy, e.g. run svn checkout and see whether you get the error or not.

  • Is the repository corrupted? Run svnadmin verify -q against the repository and check it's output. I guess that in your case the repository is healthy but if it is not, then the easiest solution would be to restore the repository from a backup.

Upvotes: 3

Related Questions