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.
Both JavaCVS and CVS profile in Generic VCS adds CVS version control support into NetBeans. However both modules use different command dialogs, command output components, filesystem properties, etc. This cause a pain to document and use. It needs to be synchronized as much as possible.
Proposed solution: Create a new autoload module cvssupport in the vcscore's space (vcscore/cvssupport). Put all cvs related dialogs, actions, settings and other components from vcscore, javacvs and cvs-profile modules there. Cvssupport module can be dependent on vcscore module if necessary. Create a new module javacvs-profile in vcsgeneric's profiles space (vcsgeneric/profiles/javacvs). Create a new XML profile, that will use commands from cvslib.jar. Make javacvs-profile dependent on cvslib.jar and cvssupport.jar Make cvs-profile dependent on cvssupport.jar and use visual components from there. Comments/suggestions?
Should be concurrent feature according to BaseTools plans.
Upgrading to P2. This needs to be at least "should-have" task. If we do not fix this into 4.0, we'd need to rewrite JavaCVS to implement the new VCS API and it will also require more maintaining work.
Moving to vcsgeneric module, we've agreed to resolve this by creation of a new javacvs-profile module dependent on vcsgeneric module. Due to limited resources it's not possible to maintain the javacvs module and rewrite it to use the new VCS APIs. Adding a PROJECTS keyword. This needs to be resolved so that projects can use the built-in client as a version control system.
This needs to be resolved because of correct interaction with projects. => Upgrading to P1.
Adding issues@javacvs to the cc list. We're still evaluating which way to go: - rewrite JavaCVS to implement the new VCS APIs, or - write a javacvs-profile module based just on cvslib.jar instead. A comparative study of both approaches is being written.
Changing to a FEATURE so that it shows in plans. This is necessary to be implemented so that built-in CVS support will work with the new projects. It was decided to create a javacvs-profile module for vcsgeneric, that will be in the standard distribution instead of the current JavaCVS module.
Well, this is not scheduled till projects developer ready 1 (the end of November). Thus I'm moving it to Milestone 5.2 for now.
Scheduling for projects ready (according to http://ide.netbeans.org/articles/projects/Milestones.html - UI done except projects related).
According to http://ui.netbeans.org/docs/ui/vcs/vcs_40.html we suppose, that it will be possible to merge both CVS client integrations (command-line and built-in) into one profile. Through proposed conditions (issue #33693) it will be decided which client will be used.
Guys, Just wanted to throw in my 2 cents vis-a-vis the merge. - The same JavaCVS functionality must be available. - The same UI interface must be available. The last time I took a look at the generic VCS module, its UI was poor and harder to use than JavaCVS. Let me elaborate: I just used the CVS profile under the generic VCS dialog. Questions to ask: 1) Does we really need to prompt the user which environment variables are relevant to the CVS profile? 2) Do we really need to ask him what OS he's compatible with? (this belongs in a CUSTOM profile or something) 3) Do the following operations make sense under CVS? If so, what do they do? (I'm not personally familiar with them) - REMOVE versus RELEASE? What's the difference? - EDITING/WATCHES? Why is this CVS related? - DIFF textual/graphical should be grouped under one option. Same for HISTORY/ANNOTATE/LOG (use submenus?) - EXPORT should show up at the end of the list, grouped with LOGIN TO... and other options are that rarely used. This is more of a CVS administrator option than a typical-user option, and even then it is extremely rarely used.
Gili, all of your CVS menu related suggestions seem pretty rational and we are happy for such constructive feedback. However, the others should be considered from not CVS-only perspective. There are strong reasons for having both environment tab and OS info fields. We are talking here about fully customizable NetBeans plug-in module able to support every VCS system featured with command-line interface. If you are average CVS user, select CVS profile, setup appropriate info and push "Finish" unless you are *advanced* user wanting to customize something in "*Advanced*" tab. I hope you understand it.
Gili, thanks for your comments. > - The same JavaCVS functionality must be available. Yes, it will. We will use the same Java CVS client library therefore all commands can be reused (although there has to be written command-line interface for some of them). > - The same UI interface must be available. We are already transferred the UI from JavaCVS. After I've merged VCS modules from prj40_prototype branch to trunk there is already the same UI defined for command-line CVS and for JavaCVS. > 1) Does we really need to prompt the user which environment > variables You can finish the wizard sooner if you do not care about environment. But yes, we should allow to change the environment. There's a bunch of CVS-related environment variables which alter the behavior of CVS. > 2) Do we really need to ask him what OS he's compatible with? (this > belongs in a CUSTOM profile or something) Perhaps this is not the best place, but yes, the profiles can be defined for certain operating systems. You should leave the default if it works for you. In NetBeans 4.0 we'll hopefuly have a centralized profile-editing place where these properties naturally belongs to. > 3) Do the following operations make sense under CVS? If so, what do > they do? (I'm not personally familiar with them) Please consult the CVS manual. > - REMOVE versus RELEASE? What's the difference? Remove removes a file from CVS (marks it as 'dead' in repository). Release removes a directory structure from a working directory. It checks whether there are any changes and if not, all up-to-date files are deleted. But only locally, no changes are propagated to the repository. > - EDITING/WATCHES? Why is this CVS related? Use this when you need to know what are other working on. Consult the manual for details. > - DIFF textual/graphical should be grouped under one option. You mean nested one level down? I'm not sure that it's worth to create a submenu for two items. I do diffs pretty often and having to go to a submenu does not seem comfortable to me. > Same for HISTORY/ANNOTATE/LOG (use submenus?) Yes, this looks reasonable. They are not so often used (Annotate is perhaps the most useful, Log has a better alternative - Versioning Explorer) > - EXPORT should show up at the end of the list, grouped with > LOGIN TO... and other options are that rarely used. I don't see a reason why export should be grouped with login. It has absolutely nothing do with it. > This is > more of a CVS administrator option than a typical-user option, > and even then it is extremely rarely used. No. User needs to login/logout. Export is also not typically done by an administrator bu someone who actually needs to retrieve the codebase for some reason. This is typically the developer (IDE user). > are relevant to the CVS profile? Of course they are. But it's a question whether these "global" commands like Import, Checkout and Export should be on the context popup menu. There are rarely used. Recently there were added Global Commands into the Versioning mnu. They were intended mainly for 4.0 release, but they can be useful in 3.6 as well. We could perhaps remove Import, Checkout and Export from the context popup menu and leave it only in the Global Commands.
> We could perhaps remove Import, Checkout and Export from > the context popup menu and leave it only in the Global Commands. Not sure if I account for a typical CVS user, but I'd leave "Checkout" in context menu, because I often do checkouts of some small subdirectories, lurk in there, maybe commit a bugfix, and then erase the directory locally. I'd appreciate an easily customizable Context menu if Checkout isn't there by default.
I also vote for having Log, Annotate and History commands grouped. As for Check Out, I would put it together with Import and Export to static commands section. Don't worry Maxym, you can always return it back to the popup menu if you really need it.
Removing the PROJECTS keyword. This is being solved in trunk.
The distance between checkboxes and radio buttons was reduced in all input dialogs to improve the visual appearance: /cvs/vcscore/src/org/netbeans/modules/vcscore/util/VariableInputDialog.java,v <-- VariableInputDialog.java new revision: 1.63; previous revision: 1.62 This was done mainly because some dialogs will be more complex after all options that JavaCVS have are defined in CVS profile.
Issue #37908 was fixed, thus from now when you select the built-in client in the "Generic VCS" wizard (or Customizer), you will get CVS commands from the javacvs library. Now a compatibility module, that will transfer javacvs filesystems into generic VCS filesystems needs to be written (issue #37883).
JavaCVS module was removed from the standard dev build and replaced with javacvscompat.jar - compatibility module that transfers the JavaCVS filesystems. Also CVS mounting wizard was removed. Use Mount -> Vresion Control -> Generic VCS and select CVS profile to mount CVS filesystem.
Martin, why use Mount -> Version Control -> Generic VCS (two levels deep), maybe it's better to use Mount -> Versioned System (or similiar, one level deep) Now when there's no JavaCVS, is there anything left in that submenu that reasons it's existance
Good point Maxym. There's already issue #37877 for that.
*** Issue 28001 has been marked as a duplicate of this issue. ***
All dependent issues were resolved, so I propose to close this as fixed as well. Further problems can be solved as separate issues. There was also a request to group Log, History and Annotate into one sub-menu. What should be the name of that sub-menu? I propose "History", because the information these commands provide are from files history: ________ Status History -> Log ________ History Annotate Do you agree?
History sounds like a good name.
I also agree. Act quickly, this Friday is feature freeze and we are writing test specifications ...
Thanks for the comments. It's in the trunk: /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/Bundle.properties,v <-- Bundle.properties new revision: 1.24; previous revision: 1.23 done Checking in cvs.xml; /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvs.xml,v <-- cvs.xml new revision: 1.17; previous revision: 1.16 Also the mnemonics were corrected. All dependent issues are fixed => this is fixed.
Very good work has been done. I've found a small thing which was forgoten and it is described in the issue #40133