Community
Participate
Working Groups
The IdenticalResourceMinimizer when looking for candidates to binary compare in order to reduce the scope of the comparison and conflict detection only looks for files with the same name, leaving out the path (normally relative to the workspace / repository root). Probably it doesn't have much effect at all, but it may cause some issues in very concrete cases where files has the same names but differenciated by forlders.
New Gerrit change created: https://git.eclipse.org/r/106202
This was the behavior we intended: the URIs themselves will not match for local comparisons (as you've realized when you needed to "fix" a test case that explicitely tested that), and they often won't match either for remote comparisons since a local URI (file: or platform:/resource) will not match a remote URI (http, https, git). If you have a specific use case for which you need the URIs to match instead of the file names, please add this to this bugzilla so that I can know what you're trying to achieve.
Thanks for your feedback, Laurent. Well, I agree with what you say in general, however, for normal git comparisons, the remote storage is a WorkspaceGitBlobStorage adapting to an IStoragePathProvider for which oeec.ide.utils.ResourceUtil.createURIFor(IStorage) will be able to create the corresponding platform resource URI. This change hence positively affects the normal Git compare scenarios. For local comparisons, you are certainly right. It won't work as the compared files can't have the same URI. However, one could argue that the simple name check also doesn't necessarily work -- the compared files could have a different name as well. Anyways, if we fail to match two resources correctly, the impact is rather minimal: the IdenticalResourceMinimizer "just" fails to binary-compare the correct files with each other and thus fails to remove them so that we might to some unnecessary comparison work in the worst case. If we however match wrong files with each other based on their simple file names (e.g., those files just happen to have the same name but are in different folders), there is a slight risk that we do something that we'd like to avoid. If those equally-named files happen to be binary identical, which has a rather low probability I admit, we remove them from the storage even though we shouldn't. In summary, I'd argue we should be more precise here as the cost of matches that fall through the cracks is lower (we just do unnecessary work) than the one for having false-positives (we may remove files that we shouldn't). Would you agree? I might misunderstand your argument, of course.
No, you're right on that. The number of "local" comparisons as compared to remote ones should be pretty low anyway, so arguing to keep the behavior for that reason seems petty. I cannot, however, take the time right now to properly test the suggested change for URI matching against git comparisons. The addition of the IStoragePathProvider we did back then may indeed have fixed the issues I had with the matching for binary identical resources. If you think that's enough, feel free to +2 and push, I had no problem with the propsed patch itself.
