Community
Participate
Working Groups
I recently updated Subversive to 1.0.0.I20121013-1700. From that moment on I am experiencing the following problem. Consider the following physical structure for projects: <workspace dir>\rootproject |->subproject1 |->subproject2 subproject1 and subproject2 are physically nested within the file system, however all the projects are "mounted" in Eclipse workspace as three sibling projects, so this is what I see in package/project explorer: rootproject subproject1 subproject2 To hide the subproject1 and subproject2 content from rootproject, there are two resource filters set on rootproject that hide subproject1 and subproject2 folders from the navigation views. This is what is typically achieved when you setup Eclipse projects from a Gradle multiproject, but I read this is typical for Maven projects integrated with Eclipse, too. So far so good. Now, let's say all these three projects are shared with SVN and consider the case in which I add/change (maybe also delete, I didn't test) a file in subproject1. What I see is this: rootproject >subproject1 subproject2 That is, subproject1 has outgoing changes. Perfect. However, now issue a "Refresh" on rootproject: the situation is now this: >rootproject >subproject1 subproject2 In other words, Subversive makes Eclipse think there are changes in rootproject too, even if you can't see them in project/package explorer because they corresponding files are filtered out. If you do a synchronization and switch to the Synchronize View, however, Subversive is now showing the following changes (let's assume the changed file is "test.txt"): rootproject1 |->subproject1 |->test.txt subproject1 |->test.txt So, this is the problem: Subversive is not honouring resource filters any more to determine outgoing changes. This problem was not occurring before update. This problem is really serious for us, because we absolutely need Subversive to support this project structure. There have always been some minor problems due to the fact that Eclipse does not natively support nested project structures, but the basic use cases were handled correctly. Please note I'm using SVNKit 1.7.5 connector (version 3.0.0.I20121013-1700).
>That is, subproject1 has outgoing changes. Perfect. However, now issue a >"Refresh" on rootproject: the situation is now this: > >>rootproject >>subproject1 >subproject2 > >In other words, Subversive makes Eclipse think there are changes in rootproject >too, even if you can't see them in project/package explorer because they >corresponding files are filtered out. If you do a synchronization and switch to >the Synchronize View, however, Subversive is now showing the following changes >(let's assume the changed file is "test.txt"): > >rootproject1 > |->subproject1 > |->test.txt >subproject1 > |->test.txt > >So, this is the problem: Subversive is not honouring resource filters any more to determine outgoing changes. I've created such a situation manually. Looked at it, but honestly, I do not understand yet how it should be handled (not from the technical point of view, but conceptually). What if I run an update operation on the "rootproject1"? Since in the end the operation will be performed by the client library that has no knowledge of the subprojects and Eclipse IDE, it will update/commit/switch/etc. everything. Then what? In order to make it work correctly from my point of view I should run the refresh operation for all the intersected projects too (which is not done yet in Subversive code, so it is subject to fix). But from your description it seems to me I should do the exactly opposite thing - prevent updating of those two subprojects? Is that it or did I misunderstood something? Also should I just handle those two folders inside the "rootproject1" as an ignored resources? Also there other questions too. For example, how should checkout behave while checking out such projects, share project etc.? In my opinion the simplest and the most correct fix would be to issue refresh on all the related resources when the change is done. But then all the changes will be shown for the root project too, obviously. P.S. The described case was never handled in any special way in Subversive, so all the previous versions actually have the same behaviour too (it is possible there was an issue that prevented a root project from showing its real status tough).
(In reply to comment #1) > I've created such a situation manually. Looked at it, but honestly, I do not > understand yet how it should be handled (not from the technical point of > view, but conceptually). > What if I run an update operation on the "rootproject1"? Since in the end > the operation will be performed by the client library that has no knowledge > of the subprojects and Eclipse IDE, it will update/commit/switch/etc. > everything. Then what? In order to make it work correctly from my point of > view I should run the refresh operation for all the intersected projects too > (which is not done yet in Subversive code, so it is subject to fix). But I'm telling you what I am expecting from such situations and what also Subclipse seems to do - it seems it has some dedicated behaviours for nested projects... however I still prefer Subversive for many reasons, so this is why I am here! :-) - Operations locally performed on the working copy from the root project (for instance: cleanup, switch): they should done on the whole project hierarchy; after they are finished, a refresh of the root project and of all the subprojects should be performed - Incoming operations (for instance: update, merge): they should done on the whole project hierarchy; after they are finished, a refresh of the root project and of all the subprojects should be performed - Outgoing operations and in general operations that require the user to review the changes in an intermediate dialog (for instance: commit, revert): resource filters should be respected, so if the command is issued on the root project, no suggestions about changes in the subprojects should be given to the user I know this not homogeneous, but there's a rationale behind all of this. For the first two types of operations, having Subversive apply changes on the whole project hierarchy is a bonus. In fact, consider our real case: we have a project hierarchy made up of one root project and about 20 subprojects. Having the possibility to do operations like merge and switch on the whole project hierarchy by simply applying them on the root project is what we need. Otherwise, since we're using Gradle, we could have opted for a flat project repository instead of the hierarchical one, which is better managed by Eclipse as a whole, but this would have been more problematic to manage (since 20 projects to switch/merge are really a lot, and you can't use multi-selection for these use cases...). On the other hand, conceptually commit and revert operations are much more "destructive" if things are done "under the hood"/"silently". In this case it's exactly what I expect that if I revert or commit something in the root project, no operation is performed on the subprojects, which are logically just different projects (from a "changeset" point of view). Please note that until now Subversive has always behaved in the "right" way: the only thing that it would have been to fix is that after a switch/merge operation on the root project, I have to manually issue the "refresh" command on all the projects in order to make Subversive realize what actual changes were performed on the whole workspace. Another thing that would need to be adjusted is the fact that when performing a merge, the Synchronize view is focused on the root project only, while the best would be to make if contain all changes from subprojects too. In these cases, we simply ignore the merge synchronize view and go back to the workspace SVN synchronize view (after a whole workspace refresh) in order to perform the actual merge (including resolving conflicts). On the other hand, Subversive behaved well with respect to revert and commit, too, because when these operations were issued on the root project, the dialog preview for the revert/commit operation simply allowed the user to choose among changes coming from the root project only. So, this was just perfect for our use case. Yes, maybe the best solution would be to let the user choose what behaviour wants subversive to have in the presence of nested projects, but I think the one I described would be a good default one. Another option could be this: Subversive shows an alert when the user issues an update/merge/switch operation on the root project and Subversive realizes there are nested projects, informing the user that the operation will actually have consequences on the subprojects, too. > from your description it seems to me I should do the exactly opposite thing > - prevent updating of those two subprojects? Is that it or did I > misunderstood something? Also should I just handle those two folders inside > the "rootproject1" as an ignored resources? As I wrote previously, I would accept that the update is performed on the whole projects hierarchy. Even more, for other operations for which I can't use multi-selection (i.e.: switch, merge) this is exactly what I need. Those two folders should be ignored just for revert/commit operations, which needs Subversive to compile a preview dialog where the user can review what changes he really wants to revert/commit. Revert/commit operations are actually much more "critical" operations than an "update" operation. > Also there other questions too. For example, how should checkout behave > while checking out such projects, share project etc.? Checkout is a whole different story. Actually, I never though about it. What we do right now is to check out the projects hierarchy with an external svn client, then import the whole hierarchy using the Gradle Import Wizard from the Spring Tool Suite. This import wizard can handle nested projects and also set up resource filters if needed. The standard Eclipse Project Import Wizard, in fact, can't handle nested projects. If Subversive were to support checking out nested projects, I would expect it to work like this: - when I select the root folder in the SVN repository, Subversive finds the .project file, checks out everything and sets up just the root project in the workspace - however, after checking out the whole project hierarchy, it also finds out the nested .project files in subfolders and then sets up the nested projects in the IDE accordingly However, I know that this use case requires Subversive to handle more things than it has been designed to. Honestly, I don't know how Subclipse behaves in this case. Regarding the "share project", I think it should work like now for projects that are already on the SVN repository: Subversive recognizes the SVN meta-information and allows you to use it to just "connect" the project to the SVN repository. I never found issues in this area with the current behaviour. Another case is if the project is not in SVN yet: in this case, when you connect the root project, Subversive may check in just the root project. When you subsequently connect the nested subprojects, the meta-information is found for them, so Subversive lets you choose to use project settings to simply connect them. After this has been done, the whole subproject files are simply seen as "added" and the user can commit them. > In my opinion the simplest and the most correct fix would be to issue > refresh on all the related resources when the change is done. But then all > the changes will be shown for the root project too, obviously. This is not so obvious. In fact, refreshing is ok, because makes Eclipse realize there are changes in subprojects, too. But if there's a resource filter set up on the root project for subfolder1, Subversive should simply ignore subfolder1 regarding to showing incoming/outgoing changes. On the other hand, if subfolder1 is actually the folder containing subproject1, I will see changes for it within the scope of the subproject1 project in Eclipse! > P.S. > The described case was never handled in any special way in Subversive, so > all the previous versions actually have the same behaviour too (it is > possible there was an issue that prevented a root project from showing its > real status tough). I can state for sure (since I have been using this project setup for more than a year now) that until now the problem I described in the bug description was not present with previous Subversive versions, when both using 1.6.x SVN connectors and 1.7.x SVN connectors. Maybe the case was handled by some unintentional code for which if change X was shown in project A (with A nested in B), then it wasn't also shown in project B, especially if X is in a folder which is filtered out from B thanks to a resource filter. If you feel more comfortable and if you want to make things work better with nested projects (I will *love* this, really!!!), I can open separate issues regarding the refresh issues and we can keep this report open just for handling the case described in the bug description: do not show incoming/outgoing changes in project X if project X has a resource filter that filters out the affected resources.
I'm very, very thankful to you for sharing your detailed thoughts on this matter. :) All of it seems very reasonable and I'll think of the best way to implement it. P.S. Actually, now that I think, I'm using a somewhat similar structure for my Web-projects (I have a few Eclipse projects and some files that are placed on the same level as those projects). So if there was a support for nested projects I would've been able to manage those files inside Eclipse IDE and not outside, like I'm doing it now.
OK, since this isssue to be related to Maven projects and nesting in general -- I would like to support improvements here. Alexander, do you have any specific plans here?
*** Bug 284054 has been marked as a duplicate of this bug. ***
*** Bug 311713 has been marked as a duplicate of this bug. ***
*** Bug 277800 has been marked as a duplicate of this bug. ***
*** Bug 248043 has been marked as a duplicate of this bug. ***
*** Bug 266753 has been marked as a duplicate of this bug. ***
*** Bug 287556 has been marked as a duplicate of this bug. ***
This issue has been migrated to https://gitlab.eclipse.org/eclipse/subversive/subversive/-/issues/103.
