This post was last edited by Anyilaoliu on 2013-12-17 17:07:35
A colleague a after a hard drive failure, check out the new project, overwrite the backup code with the item that was just checked out, and submit the SVN. (This should be a bad operation that has brought some trouble to several colleagues).
Before that, another colleague, B, had not been updated and submitted for about a day, and after that, colleague B had not been updated and submitted for one weeks.
After colleague B after today's SVN update operation, the code reverts to the version that colleague a uploaded. The last week's code is all gone.
Everyone is puzzled: theoretically there are discrepancies that should be reported in conflict, or merger, and why the local is replaced.
Solving.
Also, is there a way to recover?
Reply to discussion (solution)
The update operation is retrieved from SVN, as long as SVN's current version number is higher than local, there is no hint
The workaround is to roll back to the version when check out new project
However, the local code is overwritten and has not been committed before. I'm guessing it's not coming back.
The update operation is retrieved from SVN, as long as SVN's current version number is higher than local, there is no hint
Is the repository generally not always higher than the local version? It's supposed to be a merger.
The problem is, you're not submitting it.
Or not a colleague a but a colleague B.
If you submit it to SVN, you can roll it back down,
But if the local code is overwritten, the estimate is not coming back.
Whether the backed-up code has an. svn file, and if so, a direct replacement instead of a merge, there may be a reason for that!
Try to find the previous version of the file based on the time each version was submitted.
It is estimated that the backup code has an. svn file that covers the previous
SVN can see the history of the version, can find out?? The one before that? version