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.
|Summary:||Synchronize UI between JavaCVS and CVS profile in Generic VCS|
|Product:||obsolete||Reporter:||Martin Entlicher <mentlicher>|
|Component:||vcsgeneric||Assignee:||Martin Entlicher <mentlicher>|
|Severity:||blocker||CC:||issues, johnjullion, mihmax|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:||27850, 33692, 33693, 37249, 37398, 37593, 37883|
|Bug Blocks:||26422, 28001|
Description Martin Entlicher 2002-06-25 16:12:04 UTC
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.
Comment 1 Martin Entlicher 2002-08-01 19:13:50 UTC
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?
Comment 2 Jan Jancura 2002-08-30 09:49:19 UTC
Should be concurrent feature according to BaseTools plans.
Comment 3 Martin Entlicher 2002-09-12 16:33:29 UTC
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.
Comment 4 Martin Entlicher 2002-09-18 10:18:40 UTC
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.
Comment 5 Martin Entlicher 2002-09-19 17:51:24 UTC
This needs to be resolved because of correct interaction with projects. => Upgrading to P1.
Comment 6 Martin Entlicher 2002-10-14 18:01:26 UTC
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.
Comment 7 Martin Entlicher 2002-11-01 09:02:21 UTC
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.
Comment 8 Martin Entlicher 2002-11-08 15:07:37 UTC
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.
Comment 9 Martin Entlicher 2003-05-16 18:08:39 UTC
Scheduling for projects ready (according to http://ide.netbeans.org/articles/projects/Milestones.html - UI done except projects related).
Comment 10 Martin Entlicher 2003-05-21 15:48:18 UTC
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.
Comment 11 _ gtzabari 2003-11-03 12:56:08 UTC
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.
Comment 12 Jiri Kovalsky 2003-11-03 13:57:52 UTC
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.
Comment 13 Martin Entlicher 2003-11-13 16:27:35 UTC
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.
Comment 14 _ mihmax 2003-11-13 18:42:16 UTC
> 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.
Comment 15 Jiri Kovalsky 2003-11-14 07:52:45 UTC
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.
Comment 16 Martin Entlicher 2003-11-20 12:37:53 UTC
Removing the PROJECTS keyword. This is being solved in trunk.
Comment 17 Martin Entlicher 2003-12-09 17:05:03 UTC
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.
Comment 18 Martin Entlicher 2003-12-11 09:06:17 UTC
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).
Comment 19 Martin Entlicher 2003-12-15 17:37:46 UTC
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.
Comment 20 _ mihmax 2003-12-17 15:26:53 UTC
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
Comment 21 Martin Entlicher 2003-12-18 10:32:50 UTC
Good point Maxym. There's already issue #37877 for that.
Comment 22 Martin Entlicher 2004-01-07 10:58:07 UTC
*** Issue 28001 has been marked as a duplicate of this issue. ***
Comment 23 Martin Entlicher 2004-01-07 11:11:07 UTC
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?
Comment 24 John Jullion-ceccarelli 2004-01-07 12:19:02 UTC
History sounds like a good name.
Comment 25 Jiri Kovalsky 2004-01-07 12:34:12 UTC
I also agree. Act quickly, this Friday is feature freeze and we are writing test specifications ...
Comment 26 Martin Entlicher 2004-01-07 13:25:54 UTC
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.
Comment 27 dmladek 2004-02-16 14:21:57 UTC
Very good work has been done. I've found a small thing which was forgoten and it is described in the issue #40133