Description Justin Hickey 2012-10-26 17:10:18 EDT

Created attachment 222893 [details]
Image of software installed in Eclipse

Overview:

If a Windows process other than Eclipse or SVN has locked a file in the repository and you try to update the file, the resultant error state seems to corrupt the SVN metadata of the repository and disconnects the project from the repository. Reconnecting the project through "Team->Share Project" seems to want to import the local copy to the repository, which would wipe out all previous versions from the repository (obviously I never tested this). The only other option seems to be to delete the local copy and checkout a fresh version of the repository. The only issue here is that any local changes can be potentially lost if you're not careful.

Reproduceable:

Always

Steps to Reproduce:

1. Check out a repository for 2 independant local copies, for example on 2 different machines (say machine 1 and machine 2).

2. Once the checkouts are done, on machine 1 change a file and commit the file to the repository

edit test/file.txt
svn commit -m "testing" test/file.txt

3. On machine 2, lock the local copy of the file with a Windows program. You can use the "more" command if the file has more lines than your terminal window.

more test/file.txt

4. On machine 2, in Eclipse, right click on "test" and select "Team->Update"

Errors produced:

a. Popup window 1
Get all resources operation failed.
Previous operation has not finished; run 'cleanup' if it was interrupted

b. Popup window 2
Some resources were not updated.
Access is denied.
svn:Can't move 'C:\test\.svn\tmp\svn-F30CAC1A' to 'C:\test\file.txt: Access is denied.

Several repeated error messages appear but they are not important for this report.

This error is OK and is understandable. Since Windows locked the file, it can't be overwritten by the update.

5. Try to perform the SVN cleanup as suggested in the error message by right click on "test" and select "Team->Cleanup"

Unfortunately the "Cleanup" option is greyed out as well as most other options under the "Team" menu, including "Update". So these operations are not available. Basically, working with the repository is unreliable at this point.

6. Exit Eclipse

7. Remove the lock on test/file.txt

Quit the "more" command

8. Open Eclipse and the following error pops up:

SVN: '0x00000000: Open Project' operation finished with error: 0x00000000: Unable connect to 'test' project.
Please check that SVN meta-information exists and its format is supported by the current SVN plug-in version.
If so, it is possible that the project working copy is relocated outside plug-in control.
At the current moment project will be automatically disconnected from source control.

Steps 5-8 indicate the actual bug. The local copy is disconnected from the repository due to what appears to be corrupt meta-information. As stated above, trying to connect again by sharing the project looks like it will wipe out the repository on the server, so my only option is to delete the local copy and check out again.

Additional Platforms:

I tested this issue in Linux by executing steps 1-4 and there was no error. This is due to the fact that the Linux operating system does not lock files when they are opened. From this, I will also assume that this is not an issue on most operating systems based on UNIX.

Additional Information:

I am submitting this as a Subversive bug since running the exact same steps using the Subclipse plug in, produces the first error as expected. However, the "Cleanup" option is not greyed out in Subclipse, and running the "Team->Cleanup" command fixes the SVN state. Then, after removing the lock on test/file.txt, I was able to successfully update the file and continue my work. 

This is what I consider to be the expected functionality. Unfortunately, it appears that Subversive is somehow corrupting the repository such that a "Cleanup" operation cannot be performed.

Also, please find attached an image of the software I have installed on my Eclipse installation. This image was taken after I updated all my Eclipse software (today - Oct 26, 2012) and checked that the bug still existed.

Thank you for your time in this matter.