Community
Participate
Working Groups
I have a problem of loading the ancestor revision for the following double file move case. Base (ancestor) model: ====================== /Blank Model.emx | +--- /folder1/ModelFragment_1.efx.efx Remote model: User 1 moved file ModelFragment_1.efx from folder1 to folder2 and committed the changed ============= /Blank Model.emx | +--- /foler2/ModelFragment_1.efx Local model: User 2 moved file ModelFragment_1.efx from folder1 to folder3 and and do update ============ /Blank Model.emx | +---/folder3/ModelFragment_1.efx When user 2 do update, he gets an incoming add delta for /folder2/ModelFragment_1.efx and a outgoing add delta for /folder3/ModelFragment_1.efx. But there is no delta for /folder1/ModelFragment_1.efx on the synchronize tree. So, there is no way of getting the content of the common ancestor revision /folder1/ModelFragment_1.efx. I also try to fetch the ancestor content from RemoteResourceMappingContext.fetchBaseContents(IFile file,...) But it is empty. I tested with text files and it also does NOT show the outgoing delete either Base: /testText/folder1/test1.txt Remote: /testText/folder2/test1.txt (file test1.txt moved from folder1 to new folder2) Local: /testText/folder3/test1.txt (file test1.txt moved from folder1 to new folder3) There is NO outgoing delete of /testText/folder1/test1.txt shown in the diff tree. For normal file operation (text file, java file), this automatically deletion is acceptable since user don't need to take action for double deletion case. But not for the logical model merge case. As you can see from the logical model merge, there are conflicting changes with other files in the logical model and we need to perform the full context logical merge. So, we need to load all files belong to the logical models from 3 contributors. Also there could be changes from the deleted file that the user need to know of (ie. elements moved out from the deleted file into other sub unit files). The user may also want to revert the double file moved operation and put the file back to the original location (ie. under folder1) by reject the incoming deletion and reject the outgoing deletion via the IMergeContext.reject() method.
For CVS, deletion conflicts are auto-reconciled during synchronize. To fix this bug, the delete conflict would need to be kept and made available to the models. Although some models may hide the deletion conflict and handle it properly, other models may just surface the conflict in the UI for the user to deal with. For example, the Resources model would need to surface the conflict since there would be no other way to represent it (i.e. it isn't associated with some other visible element). This will be confusing for the average user.
*** Bug 145616 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
