Bugzilla – Full Text Bug Listing
| Summary: | "Ignored resources" randomly not respected. | ||
|---|---|---|---|
| Product: | [Technology] Subversive | Reporter: | Kresten Peter Vester <kresten+eclipse> |
| Component: | Core | Assignee: | Igor Burilo <igor.burilo> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | a.gurov, mauromol |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
The code in question is provided by the Subversive so moving to Subversive for comment. If it turns out to be a Team issue, feel free to reassign. Honestly, I do not understand what is going on.
1) The "bin" folder shouldn't have any .svn folders inside in any case, because it is the output folder, right?
2) There is the "JDT Ignore Extension" plug-in for Subversive which prevents Subversive from adding the output folder to the source control (as the output folder itself is not an autogenerated item)
3) Deeper subfolders in the output folder should not have any .svn folders even without "JDT Ignore Extension" plug-in, because they're autogenerated ones
4) Builder copies source folders into the output folder before compiling them, but .svn folders shouldn't be copied as a Team-private members
5) There is a part of code in SVNTeamMoveDeleteHook that checks if there is a need for Team Provider to operate over the resources in order to do correct deletion:
protected boolean doDelete(final IResourceTree tree, final IResource resource, int updateFlags, IProgressMonitor monitor) {
ILocalResource local = SVNRemoteStorage.instance().asLocalResource(resource);
if (IStateFilter.SF_INTERNAL_INVALID.accept(local) || IStateFilter.SF_NOTEXISTS.accept(local) || IStateFilter.SF_UNVERSIONED.accept(local)) {
return FileUtility.isSVNInternals(resource);
}
So, after checking all the data I have on hands it seems that the problem is hidden somewhere else: there should be something in your Eclipse installation that ignores "Team-private" status for resources, copies them, then deletes "Team-private" resources asynchronously, while Subversive already accepted these resources as the versioned ones. It's a very strange situation but I can't think of anything else. And if it is really going like this, then the only way to "solve" the issue by the Subversive side is to silence error reporting and force deletion even if the error occurs. But I don't like this type of "solutions" very much and can't reproduce the issue with proposed steps. Although I don't have any access to that much of projects connected to SVN. So, is there any easier way to reproduce the issue than having more than 280 plug-ins in workspace (my current limit is 55 plug-in projects)?
(In reply to comment #2) > Honestly, I do not understand what is going on. > 1) The "bin" folder shouldn't have any .svn folders inside in any case, because it is the output folder, right? Yes it is the output folder - and there are no .svn folders in the bin folder! A simple clean on the project fixes it. > 2) There is the "JDT Ignore Extension" plug-in for Subversive which prevents > Subversive from adding the output folder to the source control (as the output > folder itself is not an autogenerated item) - and I have that installed > 3) Deeper subfolders in the output folder should not have any .svn folders even without "JDT Ignore Extension" plug-in, because they're autogenerated ones - and they don't have any .svn folders. > 4) Builder copies source folders into the output folder before compiling them, but .svn folders shouldn't be copied as a Team-private members Agreed > 5) There is a part of code in SVNTeamMoveDeleteHook that checks if there is a > need for Team Provider to operate over the resources in order to do correct > deletion: > protected boolean doDelete(final IResourceTree tree, final IResource > resource, int updateFlags, IProgressMonitor monitor) { > ILocalResource local = > SVNRemoteStorage.instance().asLocalResource(resource); > if (IStateFilter.SF_INTERNAL_INVALID.accept(local) || > IStateFilter.SF_NOTEXISTS.accept(local) || > IStateFilter.SF_UNVERSIONED.accept(local)) { > return FileUtility.isSVNInternals(resource); > } > > So, after checking all the data I have on hands it seems that the problem is > hidden somewhere else: there should be something in your Eclipse installation > that ignores "Team-private" status for resources, copies them, then deletes > "Team-private" resources asynchronously, while Subversive already accepted > these resources as the versioned ones. It's a very strange situation but I > can't think of anything else. And if it is really going like this, then the > only way to "solve" the issue by the Subversive side is to silence error > reporting and force deletion even if the error occurs. But I don't like this > type of "solutions" very much and can't reproduce the issue with proposed > steps. Although I don't have any access to that much of projects connected to > SVN. So, is there any easier way to reproduce the issue than having more than > 280 plug-ins in workspace (my current limit is 55 plug-in projects)? I haven't found another way to recreate it but I will keep you posted if I find another way to recreate it. (In reply to comment #2) > Honestly, I do not understand what is going on. > 1) The "bin" folder shouldn't have any .svn folders inside in any case, because > it is the output folder, right? > 2) There is the "JDT Ignore Extension" plug-in for Subversive which prevents > Subversive from adding the output folder to the source control (as the output > folder itself is not an autogenerated item) I don't know if this is causing the bug described here, however points 1. and 2. could be violated by bug #361831. There was a problem that causes exactly the described situation: bug #361831. *** This bug has been marked as a duplicate of bug 361831 *** |
Build Identifier: 20110615-0604 I use the latest SVNKit connector with Subversive in Eclipse. It randomly happens that this exception occurs. 'bin' is in my list of ignored resources in both Eclipse and my .subversion folder. I have A LOT of plugins in my workspace 280+. When I clean the individual projects it works again for some time. It is random which projects the error occurs for. The error message in Eclipse is: The project was not built due to "SVN: '0x00000119: Delete' operation finished with error". Fix the problem, then try refreshing this project and building it since it may be inconsistent As I see it it is correct of the connector to reject to delete it since it is not under version control - so the svn command from command line would do the same. Since bean is ignored it should not go through the SVN connector. I'm using openSUSE 11.4 64 bit and 64 bit Eclipse Indigo. !SUBENTRY 1 org.eclipse.core.resources 4 273 2011-07-01 14:32:24.011 !MESSAGE Problems encountered while deleting resources. !SUBENTRY 2 org.eclipse.team.svn.core.svnnature 4 0 2011-07-01 14:32:24.011 !MESSAGE SVN: '0x00000119: Delete' operation finished with error !SUBENTRY 3 org.eclipse.team.svn.core.svnnature 4 0 2011-07-01 14:32:24.011 !MESSAGE Deletion of '/home/kvester/work/CPM62_pm/ui/com.apc.isx.loadtestharness/bin/com' was failed. !STACK 0 org.eclipse.team.svn.core.connector.SVNConnectorException: svn: Directory '/home/kvester/work/CPM62_pm/ui/com.apc.isx.loadtestharness/bin/com/apc/.svn' containing working copy admin area is missing at org.polarion.team.svn.connector.svnkit.SVNKitConnector.handleClientException(SVNKitConnector.java:1412) at org.polarion.team.svn.connector.svnkit.SVNKitConnector.remove(SVNKitConnector.java:1205) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifier.remove(ThreadNameModifier.java:488) at org.eclipse.team.svn.core.operation.local.refactor.DeleteResourceOperation.runImpl(DeleteResourceOperation.java:101) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.operation.CompositeOperation.runImpl(CompositeOperation.java:95) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.core.SVNTeamMoveDeleteHook.runOperation(SVNTeamMoveDeleteHook.java:173) at org.eclipse.team.svn.core.SVNTeamMoveDeleteHook.doDelete(SVNTeamMoveDeleteHook.java:222) at org.eclipse.team.svn.core.SVNTeamMoveDeleteHook.deleteFolder(SVNTeamMoveDeleteHook.java:60) at org.eclipse.team.internal.core.MoveDeleteManager.deleteFolder(MoveDeleteManager.java:62) at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1934) at org.eclipse.core.internal.resources.Resource.delete(Resource.java:780) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.cleanOutputFolders(BatchImageBuilder.java:114) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:46) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:173) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: org.tigris.subversion.javahl.ClientException: svn: Directory '/home/kvester/work/CPM62_pm/ui/com.apc.isx.loadtestharness/bin/com/apc/.svn' containing working copy admin area is missing at org.tigris.subversion.javahl.JavaHLObjectFactory.throwException(JavaHLObjectFactory.java:779) at org.tmatesoft.svn.core.javahl.SVNClientImpl.throwException(SVNClientImpl.java:1924) at org.tmatesoft.svn.core.javahl.SVNClientImpl.remove(SVNClientImpl.java:605) at org.polarion.team.svn.connector.svnkit.SVNKitConnector.remove(SVNKitConnector.java:1202) ... 30 more Caused by: org.tmatesoft.svn.core.SVNException: svn: Directory '/home/kvester/work/CPM62_pm/ui/com.apc.isx.loadtestharness/bin/com/apc/.svn' containing working copy admin area is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.retrieve(SVNWCAccess.java:719) at org.tmatesoft.svn.core.internal.wc.SVNWCManager.markTreeCancellable(SVNWCManager.java:254) at org.tmatesoft.svn.core.internal.wc.SVNWCManager.delete(SVNWCManager.java:525) at org.tmatesoft.svn.core.wc.SVNWCClient.doDelete(SVNWCClient.java:1433) at org.tmatesoft.svn.core.javahl.SVNClientImpl.remove(SVNClientImpl.java:603) ... 31 more Reproducible: Sometimes Steps to Reproduce: 1. Import a lot of projects connected to SVN. 2. Build workspace