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.
Affected Sources: Command classes in javacvs/libsrc In some commandclasses i can´t find a fixed pattern in Methodname that controls the Options of an cvs command. Actually i found inconsistency in the following commands: checkout,update parameter:PruneDirectory checkout,export,tag,update, commit,log parameter:revision PruneDirectory ============== Update: setPruneDirectories(boolean) Checkout : setPruneDirectories(boolean) Update: boolean isPruneDirectories() Checkout: boolean getPruneDirectories() As the standard pattern of naming for method with a boolean return type, the name of the getPruneDirectories() should be isPruneDirectories(). Revision ======== All Methodsname for the -r parameter should follow one pattern. (except: diff command) Example: setByRevision,getByRevision Not: setCheckoutByRevision, setExportByRevision, setTagByRevision, setUpdateByRevision, setToRevisionOrBranch, setRevisionFilter. OK, I can you the setCVSCommand Method to set the options. But it would more consistency if all Methods follow an simple pattern. The old Methods should than be marked as deprecated. I think that interfaces ByRevision,PruneDirectories,CleanCopy and so on, would be a nice addition to the command classes. If you need help by the implementation, i can do the work.
ageeed. The pruneDirectory getters are inconsistent. the revision stuff could be also changed. if we set the old methods deprecated, I have no problems with that.. please note that the filesystem uses wrapper classes based on reflection, which need a certain name. I'll need to change that as well. please justify the need for the interface (preferably on dev@javacvs.netbeans.org) I don't quite follow right now what is the advantage.
found additional Options with inconsistent Methodnames: KeywordSubstitution : add,checkout,update: set/getKeywordSubst export,import set/getKeywordSubstitutionOptions Message: add,commit: set/getMessage import: set/getLogMessage Ok. And now i try to explain, why of my point of view, Interfaces for Options would be nice. I have build some small UI Components(for each Optiontyp) that can be connected with a Command. Actually the UI Component searches inside the Methodtable of the given Command instance(Class). It is more easier and less bug-prone if a can ask the instance if it is from the specific Interface. I don´t know if it is the right way to programm with this libary, but for me, it looks more flexible. I see no disadvantages, only the implementation work. And as i sayed. I'm ready to do the work.
please send the proposal to dev@javacvs.netbeans.org.. I'm probably the only one of the cvs client developers who reads the issuezilla. Personally I don't have a problem with that.. the only concern is that it will increase the class count (which has memory/performance consequences.. not a problem for small scale apps, however starts to bother you when you have apps of Forte4J size)
Set target milestone to TBD