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 43233 - CVS commands on Java package nodes should be available and operate nonrecursively
Summary: CVS commands on Java package nodes should be available and operate nonrecursi...
Status: RESOLVED DUPLICATE of bug 52271
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Petr Hrebejk
Keywords: API
Depends on: 52271
Blocks: 41535
  Show dependency tree
Reported: 2004-05-13 18:53 UTC by Jaroslav Tulach
Modified: 2008-06-27 00:56 UTC (History)
3 users (show)

See Also:
Exception Reporter:

Fix. (21.07 KB, patch)
2004-05-13 18:54 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2004-05-13 18:53:45 UTC
If you select java package in logical view that
has some subpackages and invoke a CVS command, it
also processes the objects in subpackages, which
is very unexpected due to the logical view
structure. Probably the CVS should operate only on
the objects that are directly visible under the
java package node in the logical view.
Comment 1 Jaroslav Tulach 2004-05-13 18:54:11 UTC
Created attachment 14853 [details]
Comment 2 Jaroslav Tulach 2004-05-13 18:59:46 UTC
The fix replaces default FileSystemAction by one that instead on
selected java package operates on node children of that package. As
these children do not include subfolders of subpackages, the actual
CVS operation is invoked only on direct content of the package.

This would not work without ContextAwareAction interface and also
requires that all actions involved correctly implement that interface.
FileSystemAction does, NodeActions without own presenter as well, but
I had to modify some one action in vcscore as it had its own presenter
and was not dealing with ContextAwareAction interface correctly. 

I tested the functionality on CVS->Update and CVS->Diff. Worked as I
expected. I think that ShowVersions does not work, probably because it
also has own presenter and does not implement ContextAwareAction
interface as it should. I have not tested other actions.
Comment 3 Jesse Glick 2004-05-14 16:43:08 UTC
Interesting but I don't trust such a fix. (1) Will probably not
correctly handle removed files, e.g. if you try to commit the package.
(2) Will probably not correctly handle files that are hidden from the
package view.

Would prefer to simply remove FileSystemAction from package nodes
until it can be fixed to work simply and correctly. No lookup or node
tricks. Should work like the Search API does - you should be able to
tell the VCS explicitly that you wish to perform operations on a given
folder, but not to do them recursively. E.g. for CVS it could behave
exactly as now but pass the '-l' option. Would require a better API
than FileSystemAction.
Comment 4 Jaroslav Tulach 2004-05-17 09:32:18 UTC
Re1: Right now that would work, as also files not visible locally are
presented as fileobjects. I know that this will not last long, but
even if deleted, doing remove from logical view is a bit unlogical.
The important things to do from logical view include diff, update,
commit and they can work correctly. Mangling with amount of files
would be more natural from physical view.

Re2: The package node can decide which files it wants to pass to CVS
command. This is not limited to the subnodes, that is just current
impl. It can be anything.

The whole purpose of this solution is to show that we can implement
basic VCS support in logical views without a need to invent something
new which we could hardly manage till feature freeze. I'd rather live
with my changes than remove VCS support from the logical view completely.

Comment 5 Jesse Glick 2004-05-17 17:00:46 UTC
I just don't think the approach of having some random UI component
(the package view) trying to collect a list of files to pass to the
VCS is safe enough for production code. The VCS should receive a
request to update/commit/diff/etc. a particular folder,
nonrecursively, and handle this directly however it is best able. It
is not appropriate for the *IDE*, much less the package view, to be
enumerating particular files to work on.
Comment 6 Jaroslav Tulach 2004-05-18 08:53:25 UTC
The pros of your solution is that VCS can optimize for this kind of
request upd/diff -l. The cons are that we will need to somehow enhance
communication between view and VCS to support the "-l" option which is
very limiting (one would say that it works for the package view by a
chance) - the view should know the objects it wants the VCS to operate
and we should not restrict it to subtree or folder.

Resources comment: If I had to choose between not having VCS support
in logical view (contingency plan) at all or my solution (already
working), I would definitively choose the later.
Comment 7 Jesse Glick 2004-05-18 17:04:05 UTC
"the view should know the objects it wants the VCS to operate" - nice,
but sometimes it can't.

"and we should not restrict it to subtree or folder" - providing the
option of telling the VCS exactly what you want it to do is not
restricting it. If the user actually *wanted and asked* to operate on
a selected explicit list of files, that should probably be supported too.

I'm just saying that it is better to ask the VCS to operate on a
folder, and let the VCS decide which files that should include
(according to possibly complex semantics with hidden files, ignored
files, etc.) then to guess that from outside code which is completely
unaware of the details of how the VCS works.

E.g. if I have a folder f with files a, b, c, and .cvsignore of which

- .cvsignore: up to date
- a: up to date
- b: locally modified
- c: not in CVS, listed in .cvsignore

I would expect that if I right-click f and choose CVS -> Status, I
will be told:

.cvsignore - up to date
a          - up to date
b          - locally modified

as I would get from "cvs stat -l f".

If the IDE tries to call "cvs stat f/a f/b f/c f/.cvsignore" I will get

.cvsignore - up to date
a          - up to date
b          - locally modified
c          - unknown

which is not correct behavior for CVS.

I can imagine other VCS systems also having their own idiosyncrasies
w.r.t. passing a list of files vs. passing the directory.

So I would prefer to leave VCS operations to the Files tab - where we
know they do what they are supposed to be doing - than to introduce a
UI in the Projects tab which tries to be clever and seems to be doing
something but actually does something else.

Anyway re. resource constraints, what is the big deal with providing
an API to pass nonrecursive folder info to the VCS? Marian Petras did
it for search with no apparent problems and it works fine; the code is
quite straightforward and the API is tiny. We could certainly do it
right for D if we wanted to.

Will leave it to Martin to comment further.
Comment 8 Martin Entlicher 2004-05-18 17:28:54 UTC
I have to agree with Jesse. The example with .cvsignore says it
clearly. Considering all files in the folder as selected for the
operation can lead to incorrect behavior. E.g. when I call "cvs add c"
it will add it even though it's in the ignore list. But when I call
Add on a folder, it will exclude the ignored files.

VCS commands are not currently ready for setting the recursive
behavior programatically, but with usage of VCS APIs this can be
Comment 9 Martin Entlicher 2004-05-18 18:19:22 UTC
Regarding the API, I've tallked to Marian Petras, the API that is used
for search could be almost reused for this purpose if there's a public
getter for "recursive" field in SimpleSearchInfo. SimpleSearchInfo can
be retrieved from the lookup of the selected node. It would be a hack,
but it should work.
Comment 10 Jesse Glick 2004-05-18 18:35:53 UTC
Hmm, definitely a hack... would consider it but would certainly prefer
to have a proper API intended for VCS. Or to introduce an API object
(o.o.filesystems?) to represent a nonrecursive folder (intended for
Node.lookup etc.) which would be used by VCS and also be checked by
the file-based search types (which would also permit us to remove the
dep j2seproject -> openidex, BTW).
Comment 11 Jesse Glick 2004-05-18 18:47:08 UTC
BTW another option would be to use o.n.api.project.SourceGroup, which
can represent a folder with some exclusions, a display name, etc.
Would be reasonable for search, but not so good for VCS, since there
is no direct way to extract from this the fact that it represents just
files directly in the folder and no subfolders - you would have to ask
about each child, one by one.
Comment 12 Jesse Glick 2004-06-15 13:18:50 UTC
Looks like a feature for E.
Comment 13 Jesse Glick 2004-09-28 15:35:20 UTC
No definite plans.

See also issue #42659 for VCS commands on the project node and on
package root nodes such as Source Packages. This issue is just about
the context menu for package nodes.
Comment 14 Jesse Glick 2008-06-27 00:56:47 UTC
Seems to have been fixed years ago.

*** This issue has been marked as a duplicate of 52271 ***