Community
Participate
Working Groups
We have a custom logical model where we have dependencies between projects in a workspace. In our case each custom model project depends on file from another project (file named file1.txt from project named elo). During update operation after synchronization we see this exception: !ENTRY org.eclipse.core.jobs 4 2 2010-02-08 17:28:58.828 !MESSAGE An internal error occurred during: "CVS Update". !STACK 0 java.lang.IllegalArgumentException: Attempted to beginRule: P/elo, does not match outer scope rule: P/testElo11 at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:120) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:230) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:58) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:232) at org.eclipse.team.internal.ccvs.ui.operations.RepositoryProviderOperation.execute(RepositoryProviderOperation.java:279) at org.eclipse.team.internal.ccvs.ui.operations.SingleCommandOperation.execute(SingleCommandOperation.java:66) at org.eclipse.team.internal.ccvs.ui.operations.RepositoryProviderOperation.execute(RepositoryProviderOperation.java:257) at org.eclipse.team.internal.ccvs.ui.operations.RepositoryProviderOperation.execute(RepositoryProviderOperation.java:211) at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.run(CVSOperation.java:81) at org.eclipse.team.internal.ccvs.ui.subscriber.SafeUpdateOperation.safeUpdate(SafeUpdateOperation.java:370) at org.eclipse.team.internal.ccvs.ui.subscriber.WorkspaceUpdateOperation.runSafeUpdate(WorkspaceUpdateOperation.java:57) at org.eclipse.team.internal.ccvs.ui.subscriber.SafeUpdateOperation.safeUpdate(SafeUpdateOperation.java:232) at org.eclipse.team.internal.ccvs.ui.subscriber.SafeUpdateOperation.runWithProjectRule(SafeUpdateOperation.java:93) at org.eclipse.team.internal.ccvs.ui.subscriber.CVSSubscriberOperation$1.run(CVSSubscriberOperation.java:83) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.run(EclipseSynchronizer.java:1481) at org.eclipse.team.internal.ccvs.ui.subscriber.CVSSubscriberOperation.run(CVSSubscriberOperation.java:78) at org.eclipse.team.internal.ccvs.ui.subscriber.CVSSubscriberOperation.run(CVSSubscriberOperation.java:61) at org.eclipse.team.internal.ccvs.ui.subscriber.SafeUpdateOperation.run(SafeUpdateOperation.java:73) at org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:144) at org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:72) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Steps to reproduce: 1. Run eclipse with model attached to this bug. 2. Uncheck "allows models..." in cvs preference window. 3. Create project named elo. 4. Create empty file in elo project named file1.txt. 5. Import attached Model Project (testElo11). 6. Commit elo project into CVS repository. 7. Commit testElo11. 8. Checkout testElo11 using "checkout as.." with different name. 9. Make any change in file.mod in project from 8. 10. Commit this change. 11. Synchronize testElo11 (switch to Synchronize Perspective). 12. Choose update option on file file.mod. After that you should see mentioned exception.
Created attachment 158486 [details] custom model plugin
Created attachment 158487 [details] project testElo11
(In reply to comment #0) > After that you should see mentioned exception. Is the exception followed by loss of data or crash? If not, setting the severity to 'major' would be more suitable I guess.
Created attachment 158720 [details] Proposal v01
Wojtek has been working on an automated test for the issue.
Tomasz, what do you think about the proposal? I have a feeling that this may be improved, but I need your opinion on that.
The proposal looks good, I've found only two things that concerned me: 1. In org.eclipse.team.internal.ccvs.ui.subscriber.SafeUpdateOperation.getProjectsToUpdate(IProject, IResource[]) shouldn't we use: ResourceMapping[] selectedMappings = Utils.getResourceMappings(resources); instead of: ResourceMapping[] selectedMappings = Utils.getResourceMappings(new Object[] { resources[0] }); 2. After fixing 1. I did some changes in model sent by Wojciech, so that each Mod file from a Model Project references another project in the workspace. Mapping was still trivial, but I got rid of absolute path in it[1]. The point is that when I made changes to two Model projects and two projects referenced by them, the sync view showed me 4 incoming changes (good). But when I selected the mod files and did "Update" the dialog informing about other resources taking part in the operation was displayed twice (for each project) and the SafeUpdateOperation.run(Map,IProject,IProgressMonitor) was called twice as well. I think this is not expected, but might be related to the change I made in 1. [1] resources.add(ResourcesPlugin.getWorkspace().getRoot().getProject(getResource().getProject().getName()+"-ref").getFile("file1.txt"));
(In reply to comment #7) > The proposal looks good, I've found only two things that concerned me: It's an obvious mistake. Should be ResourceMapping[] selectedMappings = Utils.getResourceMappings(resources);
Created attachment 158972 [details] testcase
(In reply to comment #7) > 2. After fixing 1. I did some changes in model sent by Wojciech, so that each > Mod file from a Model Project references another project in the workspace. This problem is not caused by the fix. I works this way right now. Try to change the model so Mod file don't reference another project in the workspace. Create two Model Projects and have incoming changes to Mod files in both projects. Sync them both, select Mod files and try to Update. You will see the same issue here. I think Update is made project by project.
Created attachment 158980 [details] Proposal v02
I committed slightly changed Proposal v02 to HEAD.
(In reply to comment #9) > Created an attachment (id=158972) > testcase Wojtek, the test works. I have some comment though. 1) You should rather create your own simple model and mapping for the test inside of org.eclipse.team.tests.cvs.core bundle. 2) Instead of the new field ModelOperation#dontPromptDuringTests, I would suggest to close the dialog programmatically in the test code. Krzysztof Daniel may give you a hint how to do this :)
Created attachment 159304 [details] testcase with model This is a testcase with model integrated into test plugin. I haven't remove ModelOperation#dontPromptDuringTest yet. I don't know how to replace it with better solution. Only one idea which comes to my head is to create new thread and implement active waiting on this dialog and close it when it will appear. Do you have any other idea?
(In reply to comment #13) > 2) Instead of the new field ModelOperation#dontPromptDuringTests, I would > suggest to close the dialog programmatically in the test code. Krzysztof Daniel > may give you a hint how to do this :) I am afraid this approach is not very suitable for this bug. The CVS test does not run in UI thread and you are not going to test the dialog but some operation. Even if Wojtek will start another thread to monitor displayed Shells, and then will look for OK button, such approach will be vulnerable for slight dialog layout change which at first sight should have no effect on the operation.
I'm saying that adding ModelOperation#dontPromptDuringTests is a last resort and I hope that Wojtek will find a better way of implementing it.
Created attachment 159413 [details] A draft about removing the dialog without to much code changes
Created attachment 159423 [details] updated testcase with model Here it is test with internal model and without a prompt.
(In reply to comment #18) The patch can't be smoothly applied i.e. there are conflicts in copyrights. Moreover even if I apply it, there is one compilation error. Please fix it.
Created attachment 159533 [details] testcase
Wojtek, the test looks better and better. Some comments though. 1. I would not be so attached to the name 'elo' :) 2. The model added with the test is too big, we don't have to copy all model classes from examples. Make it as small as necessary to run the test.
Created attachment 159767 [details] testcase Testcase with simpler model.
Created attachment 159923 [details] testcase I've made some small changes in the testcase.
Created attachment 159955 [details] Test slightly updated
I committed the test to HEAD. Wojtek, could you please prepare a supplementary patch that adds some comments to the test. Something like we have in CVSWorkspaceSubscriberTest#testIncomingChanges. Thanks.
Created attachment 160050 [details] An update to Szymon's latest patch * reverted change to the CVS UI Tests launch configuration * modified TestUpdateOperation so it no longer needs to override methods in o.e.team.cvs.ui * revert the latest change to o.e.team.cvs.ui: SafeUpdateOperation and RepositoryProviderOperation. * added some comments to the tests
Created attachment 160051 [details] mylyn/context/zip
Latest patch applied to HEAD, changes in o.e.team.cvs.ui from comment 24 have been reverted.
Marking FIXED.
