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 72191 - Show Changes Offline action
Summary: Show Changes Offline action
Status: NEW
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: CVS (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@versioncontrol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-02 20:05 UTC by Jesse Glick
Modified: 2007-01-04 17:14 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 Jesse Glick 2006-02-02 20:05:13 UTC
Not sure if this is already filed somewhere - could not find it if so.

The main reason I still use Emacs' PCL-CVS in addition to NB for CVS operations,
rather than solely NB, is that the IDE lacks any apparent equivalent to M-x
cvs-quickdir, which I consider a critical deficiency.

Main use case: I run /space/src/nb_all/nbbuild/misc/full-build-linux.sh, which

1. Runs a full clean build. Takes ~2 min.

2. Does a full CVS update on nb_all, stopping if there are any conflicts or
unknown files. (Note: this part won't work well with javacvs either, since
javacvs does not perform cvs rm on files in deleted directories, nor does it
perform cvs add on new files or new directories. So I would have to just disable
that check in the script for the benefit of IDE users; the Versioning view would
show them anyway.) Takes at least 30min but perhaps much more, depending on
server load and locks.

3. Run a full source build and runs tests. Takes perhaps 20min.

Now assuming that the script completes successfully, and I want to commit
changes, what should I do? My choices currently:

a. Using Emacs, run M-x cvs-quickdir, taking ~2 min, review changes, and commit.
(Note: requires added/removed files to be properly registered in CVS/Entries, so
if changes done using IDE, need to do this manually using command-line CVS.) The
change list is accurate, even though based only on local information, because
step #2 already reset timestamps of files which were not modified relative to
the server.

b. Using the IDE, run Show Changes in nb_all, taking maybe another hour, then
review the files listed in Versioning and commit.

c. Keep a Versioning window on nb_all open permanently and make *all* file
changes in the IDE, so that changes appear in this window as they are made.

Obviously choice (b) is out of the question at the moment, given the slowness of
our server. (I routinely make changes across many nb_all modules, so it is not
an option to restrict the view to only some CVS modules.) Choice (c) is also too
unreliable to consider seriously.

If however the IDE were enhanced to add a menu item like "Show Changes Offline",
which would solely check local working dir information, then I could use the IDE
to do my CVS operations. The action would of course not show remote changes on
the server (which I don't necessarily care about anyway); and it would assume
that files with a differing timestamp, and no local backup copy to compare to,
are in fact modified. (Any phony "modifications" would be caught by an online
diff anyway.)