1

I'm actually playing this in IDE: zend studio,which embeds svn tool, but I think it should be the same with eclipse, and even svn tool itself.

Suppose there's a directory A in the svn, do the following to reproduce:

  1. rename A as A2(out of IDE), then refresh A in IDE,and it disappears
  2. refresh parent directory of A2,named P in IDE,then A2 appears
  3. rename A2 back to A,then refresh P,it reports:Problems occured refreshing the selected resources: A2/.svn [in <project root>] does not exist

How to fix this issue now?

mysql_go
  • 2,269
  • 4
  • 20
  • 20

2 Answers2

2

This is actually not how SVN is supposed to work. Changes to directory structures, files, etc. that are contained in an SVN must be done through the IDE or other SVN-aware application, not on the file system itself (i.e. through Windows explorer).

SVN actually tracks changes to its file system, and when you work around the SVN "controller" you cause the whole thing to be out of sync.

Joshua
  • 3,615
  • 1
  • 26
  • 32
  • How can I recover manually when it's out of sync?I tried to replace with repository,but still doesn't work... – mysql_go Apr 08 '11 at 15:13
1

Josh is correct. It is absolutely essential when you move or rename a file in an SVN repository that you must use SVN to do so. Svn move and svn rename (the latter being an alias for the former) have very simple syntax. TortoiseSVN supports the operation as well. In this manner the next time another user tries to do an SVN operation, the program will see that the repository has changed. If you don't tell the repository when the structure changes, you're going to confuse it like this.

To fix the problem, I would:

  1. Check out a brand new copy of your repository.
  2. Copy the folder -- whether is A or A2 -- out of the repository to save your data.
  3. Svn delete A or A2.
  4. Svn commit.
  5. Copy A or A2 back into the repository.
  6. Svn add A or A2.
  7. Svn commit.
Bacon Bits
  • 30,782
  • 5
  • 59
  • 66
  • Since svn restores all information right in file system,I guess there may be a solution that can fix it right by modifying some files? – mysql_go Apr 08 '11 at 15:52
  • I don't know. I never mess with the .svn directories or the repository directly. I would consider it too risky to try to do that. – Bacon Bits Apr 08 '11 at 18:58
  • I'm sure there's a way, but editing files in the .svn folders is unlikely to help. They're just text files with the version you checked out mostly. The repository, on the other hand, has a lot of checksumming. Editing that will likely make SVN think the repository has been tampered with and is not to be trusted. You could try deleting all .svn folders in directories below the main folder and trying an `svn update`. I doubt that will work. Like I said, the best idea is to check out a new copy and copy the files you want from the broken one. The 'fix' is starting from something good. – Bacon Bits Apr 09 '11 at 02:43
  • But the project is too large to check out completely...Is it possible to just re-check out part of it? – mysql_go Apr 09 '11 at 03:34
  • You can try checking out just P. Or P's parent. The point is to start with a new folder structure that you know SVN thinks is good. With your existing repo, P's .svn thinks A2 is an unversioned folder, but A2's .svn thinks it's still A. So depending on the context that you run SVN commands you'll end up with different results. At this point, you've probably tried several things to "fix" the problem, and so the checkout you have is inconsistent and therefore unreliable. You can't just fix the problem in the existing checkout because you've lied to SVN too much. Throw it out. – Bacon Bits Apr 09 '11 at 21:39