Bug 159543 - Commiting changes to a parent project does not commit changes to sub-projects
Commiting changes to a parent project does not commit changes to sub-projects
Status: RESOLVED FIXED
Product: versioncontrol
Classification: Unclassified
Component: Code
6.x
Macintosh All
: P3 with 3 votes (vote)
: 7.4
Assigned To: Tomas Stupka
issues@versioncontrol
: PLAN
: 167827 191543 191943 198693 206029 224794 226436 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-03 16:08 UTC by bleathem
Modified: 2013-06-14 02:01 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
suggested patch for projects (856 bytes, patch)
2013-06-12 11:35 UTC, Milos Kleint
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description bleathem 2009-03-03 16:08:10 UTC
I have a folder that consists of a maven project, with sub folders of more maven projects.  Using version control
(subversion) I am able to update all projects at once by updating the top level parent project.  However I am unable to
commit all projects at once by committing the parent project.  This is rather painful for large projects, with many modules.

This may be a duplicate of 36656, but that bug dates back to 2003, so I'm not sure.
Comment 1 Ondrej Vrabec 2009-03-03 16:33:50 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?
Comment 2 bleathem 2009-03-03 17:17:08 UTC
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).
Comment 3 bleathem 2009-03-03 17:19:50 UTC
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).
Comment 4 Ondrej Vrabec 2009-03-04 13:50:05 UTC
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.
Comment 5 bleathem 2009-03-04 16:46:44 UTC
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.
Comment 6 Ondrej Vrabec 2009-03-20 15:12:58 UTC
This behavior is a feature, not a defect.
Comment 7 Ondrej Vrabec 2009-06-30 07:39:52 UTC
*** Issue 167827 has been marked as a duplicate of this issue. ***
Comment 8 Ondrej Vrabec 2010-11-05 13:50:10 UTC
*** Bug 191543 has been marked as a duplicate of this bug. ***
Comment 9 bleathem 2010-11-05 15:04:49 UTC
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.
Comment 10 simpatico 2010-11-05 15:22:05 UTC
> 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.
Comment 11 Ondrej Vrabec 2010-11-15 08:46:26 UTC
*** Bug 191943 has been marked as a duplicate of this bug. ***
Comment 12 Ondrej Vrabec 2011-05-23 06:45:38 UTC
*** Bug 198693 has been marked as a duplicate of this bug. ***
Comment 13 svollmer 2011-09-15 13:50:46 UTC
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.
Comment 14 Ondrej Vrabec 2011-12-07 08:40:25 UTC
*** Bug 206029 has been marked as a duplicate of this bug. ***
Comment 15 Ondrej Vrabec 2012-10-12 12:56:27 UTC
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
Comment 16 Ondrej Vrabec 2013-01-12 18:55:32 UTC
*** Bug 224794 has been marked as a duplicate of this bug. ***
Comment 17 Ondrej Vrabec 2013-02-21 08:29:39 UTC
*** Bug 226436 has been marked as a duplicate of this bug. ***
Comment 18 Ondrej Vrabec 2013-02-21 08:32:20 UTC
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.
Comment 19 everflux 2013-02-21 08:38:23 UTC
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.
Comment 20 tomzi 2013-02-21 08:46:05 UTC
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....
Comment 21 Milos Kleint 2013-02-21 08:55:15 UTC
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.
Comment 22 tomzi 2013-02-21 08:59:47 UTC
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.
Comment 23 Milos Kleint 2013-02-21 09:05:37 UTC
(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
Comment 24 djvanenckevort 2013-02-21 09:17:26 UTC
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.
Comment 25 Ondrej Vrabec 2013-02-21 09:25:30 UTC
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.
Comment 26 tomzi 2013-02-21 09:48:01 UTC
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.
Comment 27 Ondrej Vrabec 2013-02-21 09:58:02 UTC
> 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
Comment 28 tomzi 2013-02-21 10:18:03 UTC
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....
Comment 29 Ondrej Vrabec 2013-02-21 10:26:23 UTC
(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.
Comment 30 tomzi 2013-02-27 10:29:53 UTC
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....
Comment 31 tomzi 2013-03-14 07:25:59 UTC
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
Comment 32 Ondrej Vrabec 2013-06-11 09:24:43 UTC
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?
Comment 33 Milos Kleint 2013-06-12 11:35:40 UTC
Created attachment 135678 [details]
suggested patch for projects

would something like the attached patch work?
Comment 34 Ondrej Vrabec 2013-06-12 13:53:12 UTC
fix: http://hg.netbeans.org/core-main/rev/524d4a8d5f58
Comment 35 Ondrej Vrabec 2013-06-12 14:01:18 UTC
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
Comment 36 Quality Engineering 2013-06-14 02:01:08 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo