Community
Participate
Working Groups
With the recent change to modifyRule, project checkouts will now lock the workspace whereas before they did not. Since we can't change modifyRule back, we should consider adding an openRule or something similar.
We are also dealing with this in Subclipse. I did not write this part of the code originally, so I do not know it all that well. Currently our checkout process only locks the project, but with 3.2 M5 the process fails because of this change. When we open the project we get an exception because the rule scopes do not match. Could we resolve this in Subclipse by beginning a new rule with a scope of workspace root before we do the project.open() and then end that rule right after. In other words, this rule would happen inside the existing rule that has a scope of the project? Thanks
*** Bug 129045 has been marked as a duplicate of this bug. ***
In Bug 129045 Comment #8 you wrote: > I considered this, but it would be a breaking change, because setDescription > says it uses modifyRule. I.e., a well behaved client will likely do (this is > pseudo-code): > > ISchedulingRule rule = factory.modifyRule(project); > try { > beginRule(rule); > project.setDescription(...); > } finally { > endRule(rule); > } Isn't this statement kind of false? Anyone who wrote and tested the above code would have got an error. Therefore, they would have changed the Rule to lock the workspace. In reality, the only code you are breaking, is code like Subclipse that had working code which relied on open project not locking the workspace. It also so happens that you not only break the code but you are adding negative side-effects in that now the entire workspace has to be locked for a potentially very long period of time. Adding an openRule() might sound like a good solution to you, but to those of us that do not have the luxury of only having to support the very latest version of Eclipse this change is of no help at all. It will probably be 2-3 years before Eclipse 3.2 is the minimum supported release for Subclipse. Thanks
(In reply to comment #3) > Adding an openRule() might sound like a good solution to you, but to those of > us that do not have the luxury of only having to support the very latest > version of Eclipse this change is of no help at all. It will probably be 2-3 > years before Eclipse 3.2 is the minimum supported release for Subclipse. It did occur to me after I posted this that if internally opening a project used this new rule, then we could go back to using the IProject for the rule and our code would work with 3.0+. That being said, when I was testing various workarounds I discovered that we also have to map the project to a RepositoryProvider and that process seemed to also use the modifyRule(). So a workspace lock would still be needed to do this.
>Isn't this statement kind of false? Anyone who wrote and tested the above code >would have got an error. Therefore, they would have changed the Rule to lock >the workspace. No, the error only occurred in certain situations. The implementation of setDescription also used the modifyRule factory method, so it is always going to be consistent with the caller using the same factory method. However, in some cases setDescription causes third party code to be called (IProjectNature#configure()) methods, and the error occurs if a project nature tries to lock the workspace or a resource outside the project.
this would be nice to be looked at for 3.3
any love on this one possibly? maybe from the new Workspace/Resources people?
Any love from Poland on this one?
(In reply to comment #0) We could use createRule instead of modifyRule during a checkout. It would behave in the same way as modifyRule used to do before. I'm investigating...
wohoo Szymon! Dziękują!
During PDE/Java project creation we call IProject#setDescription(). This method requires IWorkspaceRoot... see Bug 127562. So if we perform a checkout (with e.g. the suggested openRule that locks only a project) and than we try to create a PDE/Java project (that requires IWorkspaceRoot), the creation will wait for the end of the checkout, because those two rules are conflicting.
Created attachment 87634 [details] Proposal 01
Created attachment 87648 [details] Proposal 02 IProject#setDescription() called with IResource#AVOID_NATURE_CONFIG flag doesn't configure natures. So we can use IResourceRuleFactory#modifyRule in this case. If the flag is not specified the whole workspace will be locked. IResourceRuleFactory#modifyRule can be reverted to the previous state, so we don't have to modify team stuff. We will require some modifications in PDE/JDT. If we don't want to lock the workspace during PDE/Java projects creation, PDE/JDT have to configure natures manually.
Created attachment 87650 [details] Proposal 02
Created attachment 87653 [details] Proposal 02 tests
Fix looks good, except the rules needed by IProject#setDescrition should be specified in the API. Currently it just mentions modifyRule, but it needs to say that the root rule will be used if configuring natures.
Created attachment 87853 [details] Proposal 03 with tests
Thanks Szymon, proposal 03+tests released.
Verified in I20080205-0010.
Not sure if its related, but using Eclipse 3.4 M7 with Subclipse 1.2.4 I am no longer able to import a project set created from the same Eclipse/Subclipse. The exception looks like the one of bug 128709. Let me know if you need more info.
Hi Ben, it doesn't look like related to this one. The old problem was that project checkouts locked whole workspace. So other workspace operations had to wait till it was finished. As I understand, you can't import a project set and you get an exception. Please raise a new bug and attach the stacktrace. We can continue the investigation there.
Ok I have filed bug 230533.
I'm seeing the same problem as Benjamin #20 (the one who was told to open a new bug 230533 and then that bug was immediately closed pointing back to this one. Nice!) A casual reading of this would seem to imply that an incompatible change was made to the API that SVN depends on and the Eclipse team thinks that's OK and isn't going to change it. Say it ain't so. So what's the solution? 1. Get my project to switch to CVS like Eclipse uses, so we can be sure that support for our repository won't break? 2. Use Subversive instead of Subclipse in the hopes that Eclipse will be less likely to break one of its own projects? 3. Tell developers not to use Ganymede because M6 is buggy? Right now we're going with #3, but it would be a shame to see that be the final answer when Eclipse 3.4 is released. Note this isn't an intermittent thing. It can't read 3.3 psfs. It can't read Ganymede psfs. It always fails immediately as soon as it attempts the 2nd project in the file. This is likely one of the very first things a new developer uses. Not good.
I have made a fix to the resource rule scheduling during PSF import in Subclipse that should fix this. Basically the scope of the locking for 3.4 has changed from workspace to project (which was something we originally requested too). In current code we just lock the first project (which was OK in 3.2/3.3 because this locked the workspace. Now I am using MultiRule.combine() which I did not even know existed until now, so that all the projects being imported are locked. This seems to work fine in 3.3 and should also fix it for 3.4.
Cool. So this will appear in M7? Or Subclipse v?.? Or ...?
(In reply to comment #24) Thanks Mark for the comment and for handling the issue on the Subclipse side. I hope that you like MultiRule ;-) The fact that once the scope of modifyRule was changed from project to workspace was not good. Some could use this bad behavior to lock whole workspace, like Subclipse did. With the fix for this bug we just exposed the problem in Subclipse which should use MultiRule from the beginning.
This fix will be in a future Subclipse release. Szymon, it was Eclipse that changed this in 3.2 to lock the workspace. If you look at bug 129045 you can see where we complained and was steered towards the current code.
(In reply to comment #27) > This fix will be in a future Subclipse release. > > Szymon, it was Eclipse that changed this in 3.2 to lock the workspace. If you > look at bug 129045 you can see where we complained and was steered towards the > current code. Yes. I was not clear. When I wrote "The fact that once the scope of modifyRule was changed from project to workspace was not good.", I meant a change in Eclipse 3.2.
