Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 127987 - New Project and Shared Libraries breaks Mercurial Plugin or does it?
New Project and Shared Libraries breaks Mercurial Plugin or does it?
Status: RESOLVED FIXED
Product: versioncontrol
Classification: Unclassified
Component: Mercurial
6.x
Sun All
: P3 (vote)
: 6.x
Assigned To: issues@versioncontrol
issues@versioncontrol
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-21 09:33 UTC by John Rice
Modified: 2008-02-29 18:07 UTC (History)
7 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
main_work_70665_b1bc8c98e314-#127987-sources-outside-project2.patch (5.98 KB, text/plain)
2008-02-29 11:54 UTC, John Rice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Rice 2008-02-21 09:33:09 UTC
Creating a New Java Project from Head, results in a JavaApplication1 and libraries folder being created. As the creation
code in the Mercurial plugin looks for a common ancestor when deciding where to place the .hg directory and so what is
the parent folder of the repository, it now breaks and incorrectly puts the repository .hg under the parent of
JavaApplication1 and Libraries, in my case NetBeansProjects.

The question we have what is the expected behavior?
Should the libraries folder be under this projects control or not? If it is meant to be under VCS control then we have a
problem, what do I do when we create another New Project, is it also meant to control the Library files? I don't think
we can do this.

As it stands if I create multiple JavaApplications then they will all be in the same repository, under NetBeansProjects.
Is this what you expected to happen or not?

Some sample output:

Mercurial Initialize
--------------------
Initializing repository for JavaApplication26
Creating mercurial /export/home/jr140578/NetBeansProjects/.hg directory
The 5 project files will be added to the repository for /export/home/jr140578/NetBeansProjects/libraries on the next commit:
       /export/home/jr140578/NetBeansProjects/libraries/CopyLibs/org-netbeans-modules-java-j2seproject-copylibstask.jar
       /export/home/jr140578/NetBeansProjects/libraries/junit_4/junit-4.1.jar
       /export/home/jr140578/NetBeansProjects/libraries/junit/junit-3.8.2-api.zip
       /export/home/jr140578/NetBeansProjects/libraries/junit/junit-3.8.2.jar
       /export/home/jr140578/NetBeansProjects/libraries/nblibraries.properties
The 7 project files will be added to the repository for /export/home/jr140578/NetBeansProjects/JavaApplication26 on the
next commit:
       /export/home/jr140578/NetBeansProjects/JavaApplication26/nbproject/project.properties
       /export/home/jr140578/NetBeansProjects/JavaApplication26/nbproject/genfiles.properties
       /export/home/jr140578/NetBeansProjects/JavaApplication26/build.xml
       /export/home/jr140578/NetBeansProjects/JavaApplication26/manifest.mf
       /export/home/jr140578/NetBeansProjects/JavaApplication26/nbproject/build-impl.xml
       /export/home/jr140578/NetBeansProjects/JavaApplication26/src/javaapplication26/Main.java
       /export/home/jr140578/NetBeansProjects/JavaApplication26/nbproject/project.xml

INFO: Repository initialized, make sure to commit the new project files
INFO: End of Initialize

Mercurial Commit
----------------
init
hg add project.properties
hg add junit-3.8.2-api.zip
hg add genfiles.properties
hg add build.xml
hg add build-impl.xml
hg add manifest.mf
hg add nblibraries.properties
hg add org-netbeans-modules-java-j2seproject-copylibstask.jar
hg add junit-4.1.jar
hg add Main.java
hg add project.xml
hg add junit-3.8.2.jar
Committing 12 files to repository for JavaApplication26:
       /export/home/jr140578/NetBeansProjects/JavaApplication26/nbproject/project.properties
       /export/home/jr140578/NetBeansProjects/libraries/junit/junit-3.8.2-api.zip
       /export/home/jr140578/NetBeansProjects/JavaApplication26/nbproject/genfiles.properties
       /export/home/jr140578/NetBeansProjects/JavaApplication26/build.xml
       /export/home/jr140578/NetBeansProjects/JavaApplication26/nbproject/build-impl.xml
       /export/home/jr140578/NetBeansProjects/JavaApplication26/manifest.mf
       /export/home/jr140578/NetBeansProjects/libraries/nblibraries.properties
       /export/home/jr140578/NetBeansProjects/libraries/CopyLibs/org-netbeans-modules-java-j2seproject-copylibstask.jar
       /export/home/jr140578/NetBeansProjects/libraries/junit_4/junit-4.1.jar
       /export/home/jr140578/NetBeansProjects/JavaApplication26/src/javaapplication26/Main.java
       /export/home/jr140578/NetBeansProjects/JavaApplication26/nbproject/project.xml
       /export/home/jr140578/NetBeansProjects/libraries/junit/junit-3.8.2.jar
INFO: End of Commit
Comment 1 Jesse Glick 2008-02-21 16:29:01 UTC
IMHO creating a new repository is a rare and serious activity which should not be exposed through the IDE's GUI to begin
with. Certainly the IDE should never decide on a repo root on its own; if there must be an "Init" command in the GUI,
the user should be prompted with a filechooser where the root should be.
Comment 2 John Rice 2008-02-21 23:44:52 UTC
"creating a new repository is a rare and serious activity which should not be exposed through the IDE's GUI to begin
with"

Really? If you are setting up a large scale OpenSource project then for sure it's a rare activity, but if you are just
hacking away on your own pet projects and want the benefits of VCS or are working with a few others then it could be
quite a common experience and I think the GUI should make it simple and easy to do.

The question remains here if I create a New Java Application and put it under local Hg control, I would expect things to
just work. Now with the shared libraries being created at the same level as the JavaApplication we need to figure out
what we should do. Do we put up a file Chooser dialog and ask them to choose, they might rightly wonder why when we
bring it up we put them at a level above the JavaApplication they are creating.
Comment 3 John Rice 2008-02-21 23:45:04 UTC
"creating a new repository is a rare and serious activity which should not be exposed through the IDE's GUI to begin
with"

Really? If you are setting up a large scale OpenSource project then for sure it's a rare activity, but if you are just
hacking away on your own pet projects and want the benefits of VCS or are working with a few others then it could be
quite a common experience and I think the GUI should make it simple and easy to do.

The question remains here if I create a New Java Application and put it under local Hg control, I would expect things to
just work. Now with the shared libraries being created at the same level as the JavaApplication we need to figure out
what we should do. Do we put up a file Chooser dialog and ask them to choose, they might rightly wonder why when we
bring it up we put them at a level above the JavaApplication they are creating.
Comment 4 Jesse Glick 2008-02-22 01:58:18 UTC
My suggestion: if the project has any generic source roots not inside the project dir, such as ../libraries, warn the
user and bring up a filechooser. Otherwise assume they want to use the project dir (and maybe bring up a filechooser
anyway, but that's just my opinion).
Comment 5 David Konecny 2008-02-22 03:16:41 UTC
My two cents: I would question using project folder as root of repository. One VCS repository per project? That does not
sound like reasonable default. Unless it is HelloWorld application which you not gonna store in VCS anyway. I would say
almost always your "product" will (or should) end up implemented as multiple NetBeans projects and you wanna have all
these in one VCS repository. So we should not encourage users to create one project with huge monolithic source tree. Or
am I missing something.
Comment 6 John Rice 2008-02-22 09:36:59 UTC
OK - well with the libraries folder being created at the same level as the JavaApplicationX we need to address this issue.

Proposal:

Bring up a dialog which says something like:
--------------------------------------------------------------------------------------------
This Project has source roots not inside the NetBeans project dir (refer to Output Window).
(Mercurial repositories can only control code under the repository root)

Common ancestor for sources.
Repository root: [detected common ancestor dir]    [Browse Button]

If this is not what you want you may select your own repository root.

[OK] [Cancel] [Help]
Comment 7 Milos Kleint 2008-02-22 09:59:33 UTC
mercurial should be able to deal with this situation somehow. I wasn'tin favour of making it the default (../libraries)
but got convinced by other people that it indeed is the best default.
Comment 8 Jesse Glick 2008-02-22 14:49:43 UTC
Well NetBeansProjects is a scratch area for play projects. If people want to set up version control on some dir here, of
course we should not prevent them, but neither should we worry too much about making it useful.
Comment 9 John Rice 2008-02-25 10:09:16 UTC
Ok - so I will drop this down to a P3, as it is working as designed and make it an enhancement to bring up a dialog when
doing a Initialize so a user can choose a different root if they wish.
Comment 10 John Rice 2008-02-29 11:53:08 UTC
If the user is creating a project that will have sources outside the project dir we warn them that a common ancestor
needs to be set for root and they can cancel if they do not wish this to happen. 
Comment 11 John Rice 2008-02-29 11:54:02 UTC
Created attachment 57527 [details]
main_work_70665_b1bc8c98e314-#127987-sources-outside-project2.patch
Comment 12 Padraig Obriain 2008-02-29 13:54:41 UTC
Patch pushed in da741f833d68.
Comment 13 Jesse Glick 2008-02-29 18:07:26 UTC
Don't forget to define a Target Milestone when closing any issue as FIXED.


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