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.
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.
Created attachment 14853 [details] Fix.
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.
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.
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.
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.
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.
"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.
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 implemented.
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.
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).
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.
Looks like a feature for E.
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.
Seems to have been fixed years ago. *** This issue has been marked as a duplicate of 52271 ***