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.

Bug 157508 - Need SharabilityQuery according to declared VCS ignore lists
Summary: Need SharabilityQuery according to declared VCS ignore lists
Status: NEW
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Code (show other bugs)
Version: 6.x
Hardware: All All
: P4 blocker (vote)
Assignee: Ondrej Vrabec
URL:
Keywords:
Depends on:
Blocks: 66597
  Show dependency tree
 
Reported: 2009-01-27 17:51 UTC by Jesse Glick
Modified: 2014-06-05 12:20 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2009-01-27 17:51:36 UTC
It is difficult to ensure that all projects will reliably provide a SharabilityQueryImplementation corresponding to
every possible build product. For j2seproject, this is no problem.

For freeform projects, it is not necessarily easy - the user must have explicitly configured build directories
somewhere. (Not just build/classes/ but build/.)

For automatic projects, it is also not necessarily easy - perhaps autoproject could watch the build script to see if it
ever deletes a directory (say during a clean target), and if so, consider it unsharable. I am not sure if this is reliable.

Probably better would be to simply treat any file/dir which the VCS configuration has in fact listed as "ignored" as
unsharable. Most users of freeform and automatic projects will have already set up their VCS ignore status for other
reasons.

Specifically, there should be a (global) SQI which checks for CVS/SVN/Hg-controlled files, and if an entry in
.cvsignore/svn:ignore/.hgignore can be found, reports UNSHARABLE, else reports UNKNOWN. (If this SQI is put after the
ProjectSQI, then I think it could safely report SHARABLE or MIXED instead of UNKNOWN.) Of course the code already in VCS
which calls SQ would need to know to skip over its own SQI so there is not a logical loop.
Comment 1 Jesse Glick 2009-01-27 17:53:44 UTC
Not sure if this component is right. I cannot enter anything under "versioning", but this is not specific to a
particular VCS.
Comment 2 Tomas Stupka 2009-01-28 22:11:46 UTC
see two problem areas here:
1.) vcs support doesn't recognize files as to be ignored - reported in #64999, #65545
2.) jumpto-dialog lists irrelevant files - #153129

1.) the specific vcs ignore settings would have to be setup, but in such case there is no need for the SQ anymore.

2.) what if there will be ignored files the user works with and wants to see them in jumpto? sounds more like a
visibility problem to me or at least - i was able to get rid of #153129 via options/misc/files/ignored files pattern
Comment 3 Jesse Glick 2009-01-28 23:02:48 UTC
For #1 - there are three things to consider:

1a. For a j2seproject etc., when you make a new project, the IDE should create .ignore entries for you: for
nbproject/private, build, dist. This already works, using a SQI in the project type.

1b. For a freeform project, when you add project metadata (nbproject/), the IDE should create a .ignore for
nbproject/private. Thanks to the fix in issue #65545, this already works.

1c. For freeform or autoprojects, if you have some build folders in your project, it is up to you to list them as
ignored in your VCS if you have not already done so; the IDE cannot (generally) know where they are. So there is no real
problem here, which is why I propose to make issue #66597 WONTFIX.

For #2, I think it is correct that issue #153129 is closed; generally you would not want to be opening build products in
the editor. (You can always browse to them manually in Files if you really want to, but in my experience this is an
unusual need, and searching these folders is not only confusing but makes the search much slower.)

Editing global visibility patterns is not an acceptable workaround: ignored dir names may well be specific to the
project (e.g. some projects keep their build script in "build/build.xml", others keep build products in "target" which
is a legitimate package name component, etc.), so a global setting would be wrong; and you do not want build dirs to be
hidden from the Files tab. Anyway you should not need to go edit some regexp in the Options dialog just to have the IDE
behave properly.

Since Go to File, Find in Projects, New File, etc. all use SharabilityQuery (perhaps indirectly via SourceGroup.contains
on the generic source roots for the project) to differentiate between sources and build products, the most
straightforward way to make this also work for freeform and automatic projects (or indeed for nonstandard build products
in other project types) would be to assume that the user has already configured VCS ignore lists correctly, and to
report any files/dirs matching existing entries as unsharable using SQI.
Comment 4 Tomas Stupka 2009-01-29 19:42:56 UTC
> you do not want build dirs to be hidden from the Files tab
right:)

> Go to File, Find in Projects, New File, etc. all use SharabilityQuery (perhaps indirectly via SourceGroup.contains
> on the generic source roots for the project) to differentiate between sources and build products
sorry, i still don't get it:
1.) how will this help in case of unversioned projects?
2.) will then go to etc. bypass only files from a vcs ignored source group but not from an e.g. ignored package? 
3.) last but not least - the strange semantic in "a folder (source group) set by user to be ignored by svn" should be
intepreted as "build product". 
- ...

lowering priority to match with the blocked issue.
Comment 5 Jesse Glick 2009-01-29 19:59:14 UTC
#1 - it won't help unversioned projects at all. But I think most large freeform/automatic projects, for which this
matters most, are going to be versioned.

#2 - should work in either case. A typical impl of SourceGroup.contains for a GENERIC-type group (which e.g. GtF checks)
checks SQ on any subfolders.

#3 - there is nothing about SQ that is specific to build products, though that is certainly the most common reason for
keeping a folder out of VCS. The natural interpretation of "Go to File" is to go to a file which is "part of" the
project, implying storage in the SCM repo which defines the project.