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?

Community
  • 1
  • 1
NPS
  • 6,003
  • 11
  • 53
  • 90
  • Were there file renames? Subversion does not cope well with renames. – andref Feb 18 '17 at 20:55
  • No, these files were just removed. – NPS Feb 19 '17 at 23:38
  • What is the output of `svn stat`? – Constantin Feb 20 '17 at 01:47
  • 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. – NPS Feb 20 '17 at 14:38
  • 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. – Owl Dec 18 '18 at 17:06

1 Answers1

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
Constantin
  • 8,721
  • 13
  • 75
  • 126
  • "Before that I had a clean version of repo at revision 150 (no manual changes to files)." – NPS Feb 22 '17 at 15:18
  • Without more information on the svn changes and the working copy status, we can only guess what the root cause really was – Constantin Feb 22 '17 at 15:28
  • I know, I wrote that in the comment to my question. – NPS Feb 23 '17 at 10:26
  • 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. – NPS Feb 28 '17 at 09:24