Reverting changes failed with some skipped paths
Asked Answered
W

1

10

I've read this answer: How do I return to an older version of our code in Subversion? and used the command svn merge -r 150:140 . to revert back to an old revision (I didn't need to commit the reverted changes, just get to the old version of files). Before that I had a clean version of repo at revision 150 (no manual changes to files). Unfortunately, I got these warnings:

...
Skipped 'some/file.h'
Skipped 'some/file2.h'
...
Skipped 'some/file3.h'
Skipped 'some/file4.h'
...
Summary of conflicts:
Skipped paths: 4

Which surprises me seeing as all I wanted to do was go back to some old version of files (and I had no changes beforehand).

What could have caused this? How do I get to the old version?

Edit: I've checked and apparently these files don't exist in the currrent version (150) (either on disk or in SVN):

svn: warning: W155010: The node 'some/file.h' was not found.

But they did exist in revision 140. So somewhere along the way they were deleted. But why can't SVN just restore them?

Watcher answered 12/2, 2017 at 13:23 Comment(5)
Were there file renames? Subversion does not cope well with renames.Acrodrome
No, these files were just removed.Watcher
What is the output of svn stat?Sheepherder
Unfortunately, I don't have this repository anymore - had to move forward at my work. So I'm afraid we can't continue this thread. But I don't think I can close the bounty right now.Watcher
It can be caused by a merge conflict that you postponed, then you deleted the file locally, now it wont check out the file, wont update it, and skips it.Verdugo
S
5

The most common root cause for such a tree conflict is, that your working copy had some changes and then you try to merge - bad things can happen. Just guessing from the output, it could be related to the "some" folder (i.e. if the whole folder was removed between revision 140 and 150 - not just the files; or if you had some local changes in the skipped files before merging).

In case this happens in the future again, try to revert the failed merge by executing:

svn revert --recursive

Back on revision 150 delete any unversioned files & folders from your working copy and rerun the merge by using

svn merge -r 150:140 -v --force .

(-v will display more verbose information, --force will delete files from your working copy, even if they were modified local)

In case everything else fails, the last resort is always to just checkout a fresh working copy from revision 140 into a new local folder using

svn checkout -r 140 $your_url
Sheepherder answered 22/2, 2017 at 2:14 Comment(4)
"Before that I had a clean version of repo at revision 150 (no manual changes to files)."Watcher
Without more information on the svn changes and the working copy status, we can only guess what the root cause really wasSheepherder
I know, I wrote that in the comment to my question.Watcher
I don't understand why this answer got any upvotes - we may not be able to find the root cause but I explicitly stated that the repo was a clean checkout with no modifications and this answer points to modifications as the potential root cause.Watcher

© 2022 - 2024 — McMap. All rights reserved.