This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Commiting changes to a parent project does not commit changes to sub-projects | ||
|---|---|---|---|
| Product: | versioncontrol | Reporter: | bleathem <bleathem> |
| Component: | Code | Assignee: | Tomas Stupka <tstupka> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | anebuzelsky, djvanenckevort, everflux, heatseeker, kecampbell, mkleint, runshine, simpatico, tomzi |
| Priority: | P3 | Keywords: | PLAN |
| Version: | 6.x | ||
| Hardware: | Macintosh | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | suggested patch for projects | ||
|
Description
bleathem
2009-03-03 16:08:10 UTC
Are those projects under one common versioned folder? If you switch to File view and invoke 'Commit' from a pop-up menu on that common folder, it still doesn't commit all changes? Do you see made changes in the Versioning view after 'Show changes' action? Yes, those projects are all under one common versioned folder (see ProjectPom below). I have a checkout of the same folder on a separate linux machine, and there the svn commit at the top level works as expected. A example folder structure would be: ->ProjectPom |->Module1Pom |-->SubProject1 |-->SubProject2 |->Module2Pom |-->SubProject3 ... If I make a change to SubProjectX, and right-click on ProjectPom, the commit option is grayed out. It is grayed out in both the Projects view, and in the File view. Although in the File view it is decorated with the blue pillbox indicating a change has been made. Lastly, the commit option is also grayed out in the versioning menu when I've selected ProjectPom in either the File or Projects view (both the top level commit, and the commit under the Subversion sub-menu). Sorry, I didn't answer the last question:
> Do you see made changes in the Versioning view after 'Show changes' action?
I see "<No Local/Remote Changes>" when I do a "Show Changes" to the top level project, (even though it is decorated with
a blue pillbox).
The reason for this behavior is that those subprojects are excluded from the main project context. The maven project API 'states' (similarly as e.g. Netbeans module suite project) that these subprojects shall not be included in the performed action. This is not a bug but actually a right behavior. Actually the bug is the way the update action works - it should not update all subprojects. However there is a way to suit your needs. Do not use the Project or Files view but switch to the Favorites view (Window -> Favorites), add your ProjectPom folder into the view (from the view' pop-up menu) and try to perform subversion actions here. While this may be "true" to maven behaviour, I would suggest it's goes against the expected subversion behaviour. Perhaps the maven behaviour should apply in the Projects view, and the subversion behaviour should apply in the Files view. Thanks for pointing out that I can achieve this result using the Favorites view; I'm happy enough to accept that as a solution if you want to close this bug. This behavior is a feature, not a defect. *** Issue 167827 has been marked as a duplicate of this issue. *** *** Bug 191543 has been marked as a duplicate of this bug. *** I've given this some more thought, and I think the reasoning behind this being a feature and not a bug is incorrect. If I perform the scm functionality through the maven command line, or through netbeans mapping of the maven commands, then I would expect the maven behaviour as you described. However, if I perform the scm functionality through the netbeans scm menu itself, then I expect the standard scm behaviour. I've fallen into the workflow of switching from the projects pane to the favorites pane for performing all my scm activities, and it is a disruptive to have to do this. I would suggest adding maven scm commands under a maven context menu item, that implement the maven scm behaviour you are aspiring to, and have the scm context menu provide expected scm behaviour.
> I would suggest adding maven scm commands under a maven context menu item, that
> implement the maven scm behaviour you are aspiring to, and have the scm context
> menu provide expected scm behaviour.
I agree totally.
*** Bug 191943 has been marked as a duplicate of this bug. *** *** Bug 198693 has been marked as a duplicate of this bug. *** I agree that this issue should be considered as a bug. It is different from the expected Subversion behaviour. It took me only 1 day since I started using NetBeans to encouter this problem. *** Bug 206029 has been marked as a duplicate of this bug. *** This should indeed be fixed, the whole logic of parent and subprojects is confusing. It should be reviewed and decided how to change. This may affect not only maven subprojects but also external libraries folder for java projects or external source roots for free-form projects. In the scope of fixing this bug we should also consider other related bugs: #205619 and #207275 *** Bug 224794 has been marked as a duplicate of this bug. *** *** Bug 226436 has been marked as a duplicate of this bug. *** more and more complains are coming on the behavior of parent and sub projects. Milosi, we should talk about it and decide if we want to change it or keep it as it is now and close this as WONTFIX forever. It is especially confusing that committing when clicking on the "sources" the sub projects in fact are committed as well, while clicking on the parent project only changes of the parent project are committed. (Tested with PHP and javascript sub project) However after getting used to that it might even be a desired behaviour. I must say that this is a totally NOT obvious behaviour, since everybody working with svn 'knows' that if I do a 'Show Changes' on a parent node, I *will* get all changes of the levels below. The current behaviour does not really make sense for SVN. If the project would exist of some modules that are part of the current folder hierarchy and some modules that are not in the same folder hierarchy and would perform an SVN action I would only expect the ones IN the current folder hierarchy be part of the SVN 'update/commit', since this is what SVN does.... there are 2 different things here. The idea of subprojects and nested projects. subprojects are more or less a build related abstraction, while nested projects are filesystem location related. So in maven you can have a parent project with subprojects that are nested, but you can have subprojects that are not nested. IMHO we should be discussing just nested projects here. I totally agree! Doing SVN upgrades/Show Changes.... should only work on nested projects, or ALL the files and folders that are nested to the current project, since that's the way SVN works.
Also this current 'feature' also does not really help if people working with eclipse (or IntelliJ IDEA) want to switch or just work a little bit with Netbeans. Since there (at least in eclipse) this works as expected. And what if you would nest ant projects in a 'module' way, then, I'd think, Netbeans SVN would also work as expected, too, wouldn't it. So why making a difference with maven projects?
> there are 2 different things here. The idea of subprojects and nested projects. subprojects are more or less a build related abstraction, while nested projects are filesystem location related.
> So in maven you can have a parent project with subprojects that are nested, but you can have subprojects that are not nested.
> IMHO we should be discussing just nested projects here.
(In reply to comment #22) > Also this current 'feature' also does not really help if people working with > eclipse (or IntelliJ IDEA) want to switch or just work a little bit with > Netbeans. Since there (at least in eclipse) this works as expected. And what if > you would nest ant projects in a 'module' way, then, I'd think, Netbeans SVN > would also work as expected, too, wouldn't it. So why making a difference with > maven projects? > this is not a maven related feature, same behaviour can be observed with any project types created in nested manner I agree with Milos Kleint and tomzi. I would also like to point out that the behaviour with git is already to include the changes in nested modules. I strongly feel that the behaviour should be as much as possible the same between the different revision control systems. I am afraid that i cannot make everyone happy. The first half may be happy with the current behavior (operations run on a parent project do not affect its subprojects) and find it logical, the other half cannot simply bare it. So i incline to a possibility to have a switch (or a checkbox in the options panel) that either bypasses the behavior or not.
> I would also like to point out that the behaviour with git is already to include the changes in nested modules. I strongly feel that the behaviour should be as much as possible the same between the different revision control systems.
Yeah, that's probably a bug in Git and in fact should probably be fixed so it behaves exactly as in Subversion support.
How are the implementations in Mercurial and CVS in this regard. Do they include nested projects? If they do then SVN should act the same way, IMHO. > How are the implementations in Mercurial and CVS in this regard. Do they
> include nested projects? If they do then SVN should act the same way, IMHO.
They're the same as SVN
Well I guess then, that's a design issue - I obviousely don't know how you guys came to the decision designing the feature this way. I just can say that from a Versioning perspective, I would expect that I get all the changes of the current folder and all it's nested folder as default behaviour. Since Versioning is principally speaking independent of maven as Milos commented (if I understood him correctly) Maybe you should find out what is commonly expected and maybe even compare this feature with other IDE's. A checkbox that changes the behaviour also sounds interesting.... (In reply to comment #28) > I just can say that from a Versioning perspective, I would expect that I get > all the changes of the current folder and all it's nested folder as default > behaviour. We're not talking about folders. Again, a project is a logical structure consisting of multiple folders and excluding others (such as nested projects) there is nothing like "the current folder" hidden behind a project node. If you want to work strictly with folders then go to the Favorites view. Well, I get that, thanks for the explanation. It is still confusing. I agree with a couple of people pointing out the problem above: 1.) "I've fallen into the workflow of switching from the projects pane to the favorites pane for performing all my scm activities, and it is a disruptive to have to do this." 2.) "I would suggest adding maven scm commands under a maven context menu item, that implement the maven scm behaviour you are aspiring to, and have the scm context menu provide expected scm behaviour." 3.) "While this may be "true" to maven behaviour, I would suggest it's goes against the expected subversion behaviour. " The Problem here is that apperantly there are 2 views that conflict with each other a) the Maven scm view b) the Subversion/CVS/GIT... view Maybe there is a way to combine both views somehow (although I don't know who knows about/expects view a)) Eg when doing an 'Show Changes' to have two checkboxes [ ] include only nested projects -> nested meaning, those in the filesystem [ ] include all modules -> meaning also modules not being nested Same for the commit dialog.... Wouldn't it make sense to add some logic that checks if any of the submodules are also checked out on the filesystem and if they are, then the should be included in any SVN Action - this is IMHO what a user would expect Milosi, could you add a property to nodes from Projects view and Files view so i could tell the difference what view the nodes come from? Created attachment 135678 [details]
suggested patch for projects
would something like the attached patch work?
now it should work in the same way as the views are designed: 1) projects view - works as a logical view, does not work recursively 2) files view - works recursively Integrated into 'main-golden', will be available in build *201306132301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/524d4a8d5f58 User: Ondrej Vrabec <ovrabec@netbeans.org> Log: #159543 - Commiting changes to a parent project does not commit changes to sub-projects committing a project in the Files view should work on the project folder and should commit recursively |