Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 362219

Summary:	Synchronize with Workspace errors with "outer scope rule" when new file is not under an existing folder
Product:	[Eclipse Project] Platform	Reporter:	Rich <richtsai727>
Component:	Team	Assignee:	Malgorzata Janczarska <malgorzata.tomczyk>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert, eclipse, malgorzata.tomczyk, Marc.Herbert, remy.suen, robin, tomasz.zarna
Version:	4.3
Target Milestone:	4.3 M3
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Rich

2011-10-27 13:00:39 EDT

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.

Comment 1 Remy Suen

2011-10-30 12:09:43 EDT

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)

Comment 2 Remy Suen

2011-10-30 12:26:56 EDT

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.

Comment 3 Robin Stocker

2012-10-22 07:32:25 EDT

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?

Comment 4 Tomasz Zarna

2012-10-29 05:30:50 EDT

Gosia, could you please look at this? A fix is already there, waiting to be picked up.

Comment 5 Malgorzata Janczarska

2012-10-30 11:28:17 EDT

(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.

Comment 6 Marc Herbert

2012-10-31 04:55:13 EDT

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

Comment 7 Malgorzata Janczarska

2012-10-31 11:16:12 EDT

(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.

Comment 8 Dani Megert

2012-11-01 08:11:45 EDT

The fix looks good. Verified in 4.3-I20121031-2000.

Comment 9 Robin Stocker

2012-12-23 13:39:43 EST

*** Bug 397129 has been marked as a duplicate of this bug. ***