Community
Participate
Working Groups
Build Identifier: 1.2.0.201110190928 In order to merge a feature branch into the master without the entire history, I use "Synchronize with workspace". Any new files created under a folder that does not already exist in the master branch will give the "Attempted to beginRule... does not match outer scope rule" error when I right-click and select "merge". The merge function does not create the necessary folders in order for the new file to be created in the master branch I use "Synchronize with workspace" as a workaround for the lack of a "squash" function. Reproducible: Always Steps to Reproduce: 1.Create a new branch "SyncTest" of "master" 2.Create a new folder "folder" in "SyncTest" 3.Create a new file in "SyncTest" and commit 4.Checkout "master" branch 5.In repository view, right-click "SyncTest" and select "Synchronize with Workspace" 6.In the Synchronize perspective, right click on the new file and select merge or overwrite. 7.Error at this point.
java.lang.IllegalArgumentException: Attempted to beginRule: P/gittest, does not match outer scope rule: F/gittest/test at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:134) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:333) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:63) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:286) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:118) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2282) at org.eclipse.core.internal.resources.Folder.create(Folder.java:92) at org.eclipse.core.internal.resources.Folder.create(Folder.java:125) at org.eclipse.team.core.mapping.provider.MergeContext.ensureParentsExist(MergeContext.java:398) at org.eclipse.team.core.mapping.provider.MergeContext$5.run(MergeContext.java:353) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.team.core.mapping.provider.MergeContext.run(MergeContext.java:408) at org.eclipse.team.core.mapping.provider.MergeContext.performReplace(MergeContext.java:345) at org.eclipse.team.core.mapping.provider.MergeContext.performReplace(MergeContext.java:322) at org.eclipse.team.core.mapping.provider.MergeContext.merge(MergeContext.java:144) at org.eclipse.team.core.mapping.provider.MergeContext$3.run(MergeContext.java:87) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.team.core.mapping.provider.MergeContext.run(MergeContext.java:408) at org.eclipse.team.core.mapping.provider.MergeContext.merge(MergeContext.java:81) at org.eclipse.team.internal.ui.mapping.ResourceMergeHandler$1.execute(ResourceMergeHandler.java:58) at org.eclipse.team.ui.mapping.SynchronizationOperation.run(SynchronizationOperation.java:121) 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:54)
When the merge is invoked, IMergeContext's getMergeRule(IDiff) method is used to determine what the scheduling rule should be. The current behaviour returns the parent resource of the file (which would be the folder). Later, during the creation of the file, MergeContext's ensureParentsExist(*) method is called, and since the parent folder doesn't exist, a call is made to to create it. In this case, the required rule is at the project level so a conflict occurs and the IAE is thrown.
Reassigning to platform/team: Is this something that should be fixed in MergeContext itself? See getMergeRule here: http://git.eclipse.org/c/platform/eclipse.platform.team.git/tree/bundles/org.eclipse.team.core/src/org/eclipse/team/core/mapping/provider/MergeContext.java#n416 The !resource.exists() branch could be replaced by this: IResource parent = resource.getParent(); while (parent != null && !parent.exists()) parent = parent.getParent(); if (parent == null) rule = ResourcesPlugin.getWorkspace().getRoot(); else rule = parent; Doing this in EGit's subclass of MergeContext (GitSubscriberMergeContext) fixes the problem. Is the fix correct, and does it belong in platform/team?
Gosia, could you please look at this? A fix is already there, waiting to be picked up.
(In reply to comment #4) > Gosia, could you please look at this? A fix is already there, waiting to be > picked up. I'm looking at it.
Merely deleting a folder and trying to restore a file that was in it looks like an easier way to reproduce this bug (and maybe a more frequent way to trigger it, too) Here is the main "cannot restore file" bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=345002
(In reply to comment #3) > Doing this in EGit's subclass of MergeContext (GitSubscriberMergeContext) fixes > the problem. Is the fix correct, and does it belong in platform/team? I looked closer and it occurred Apply Patch in Synchronize View action also addressed this problem in a similar way as your proposition. In general it makes sense to return the first existing parent if the resource does not exist instead of its direct parent no meter if existing or not, so I moved this logic from ApplyPatchSubscriberMergeContext to MergeContext. I run some basic tests and verified that it fixes your problem as well.
The fix looks good. Verified in 4.3-I20121031-2000.
*** Bug 397129 has been marked as a duplicate of this bug. ***
