Community
Participate
Working Groups
Another variation of bug 307140 but this while moving a project name is also changed.
Created attachment 206522 [details] Fix with test This is a proposed fix.
Robin, I can't reproduce the problem you are describing after applying this patch. Can you verify my scenario from Bug 307140 comment 24?
I would keep the old test and add new test cases for moving with the project name change in the same time.
Created attachment 206689 [details] fix with test (In reply to comment #3) > I would keep the old test and add new test cases for moving with the project > name change in the same time. I extended current test to test both variations: when project name is changed and when it's not.
Gosia, you mentioned that your fix fixes more than is shown in tests. Please update the test so we are aware of all problems being fixed.
Created attachment 207033 [details] tests to some move variants Those are some tests I created after an offline discussion with Szymon. 1. Moving a project to a path of another project and renaming it to destination project name 2. Renaming project to ".metadata" 3. Moving a project inside the folder that is linked to this project I was expecting that Test1 will fail without my fix, but it occurred that this is validated twice. Test 2 fails after my fix and this is a very good reason to say that my fix is not good. Test 3 passes with my fix. Without it the tests never finishes because move operation in this case never finishes! One of the conclusions from our discussion that LocationValidator#validateProjectLocationURI(context, location) didn't expect that we can do both at a time: move to another location and change name (from what I learned from Szymon is that changing a name of the project is understand as creating a new project, because project is identified by name). So this validator has a mixture of two things: checking if new project can be created under given location and checking if project contents can be copied (moved) to this new location.
(In reply to comment #6) > Test 3 passes with my fix. Without it the tests never finishes because move > operation in this case never finishes! I found another situation when operation never finishes. This is copying a project into its subfolder. It can be reproduced from the UI as well (only remember to change the project's name). I have a test for it and I'll add with a fix.
Created attachment 207171 [details] fix with more tests This proposition is more complicated but fixes all potential problems I found investigating this bug. I divided validateProjectLocationURI into tree functions: 1. function that validates only the potential location without further interest in project itself (except its default location) 2. function that validates project location against other projects 3. function that validates project location against the project content This was needed because in case of moving the project 1. location itself should be validated for target project 2. validation against other projects should be made in context of source project 3. validation against project contents should be made for the source project For copying the project: 1. location itself should be validated for target project 2. validation against other projects should be made in context of both projects: source and target, to make sure that new location doesn't overlap old project but also isn't the source project subdirectory 3. validation against project contents should be made for the source project
Created attachment 207172 [details] mylyn/context/zip
Last patch pushed to Gerrit: https://git.eclipse.org/r/#/c/5243/
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.
