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 141862 - CVS Commit dialog: Modality really gets in the way
Summary: CVS Commit dialog: Modality really gets in the way
Status: NEW
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: CVS (show other bugs)
Version: 6.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: issues@versioncontrol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-28 12:40 UTC by eskild
Modified: 2009-04-02 22:41 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description eskild 2008-07-28 12:40:47 UTC
The CVS commit dialog is modal. This quickly gets in the way. Let me illustrate my point with a use case:

General idea: Open some files, edit them, then commit the changes one file at a time, since several different and
independent bugs were fixed, one bug per file. (This is a frequent real-life scenario where I work.)

1. Open a CVS-controlled project.
2. Edit some files.
3. Projects view: Right-click on project => CVS => Show Changes
4. CVS window opens. The user now wants to review what (s)he actually did to those files, so each file is double-clicked
and the diff inspected.
5. Now commit the file. The commit window opens.
6. Begin writing a suitable commit message.
7. Maybe you want to include, say, a function name but you can't remember if it's called "foo_bar" or "foo_baz", so
you'll just check the diff. But you can't.

At this point you have two ways forward: You either commit with a half-baked message, or you cancel the commit, go look
in the diff, then try to commit again. None of the two are really ideal.

My suggestion, then: The commit dialog should be non-modal. If the user messes with the file while the commit dialog is
up, then we have two strategies: Either detect it and offer a commit confirmation dialog upon the user pressing OK ("The
file has changed while your were typing the commit message. Really commit now? [Yes|No]", and "No" would return the user
to the commit dialog.), or just commit the file as it stands now -- one could argue that it's the user's own problem if
the file has been changed.
Comment 1 edgrimm17 2009-04-02 22:41:22 UTC
There is a third way forward: use a separate tool to perform the diffs.  This is exceedingly kludgy, but works - so long
as you have another tool that works.  Options include TortoiseCVS, WinCVS, and Cygwin's CVS.  I'm certain there are others.

I tend to use a modified version of the second - copy the commit message thus far, cancel the dialog, paste the commit
message into a new file, then use that new file to write up the whole commit message.  After that's finished, copy said
message, delete the file, go back into commit, paste it, and submit.

In any event, it's not the kind of issue a refined product would have.  Worse, modal windows aren't the norm in this
application, so it's clearly an issue that has been deliberately placed in the application.  I think I understand the
issue that the coder who made the dialog modal was trying to solve, and I have three alternate solutions, which I feel
are much better:

- Simply check the files for updates between the time the commit is initiated and when it is submitted, and if the files
have been updated, then abort.  This is the same behavior as the open source CVS command-line.

- Mark all of the files being committed as read-only until after the commit completes or is canceled.

- Don't stress about it - if the files are updated between when the commit is initiated and when the commit is
submitted, prompt the user to re-edit the commit text, submit anyway, or cancel.  Personally, I prefer this approach.