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.
If I have a cvs filesystem mounted, but there is a problem logging in, every directory I expand in Explorer produces another output tab saying exactly the same thing. Yes, I know you can set offline mode in the property sheet, which is no longer displayed in the main window by default. I think we've also discussed before that the user should be notified that the operation they requested failed. The operation I requested was to expand a folder. That operation succeeded. The point is: There is *no useful information whatsoever* in all these tabs. There is *absolutely no purpose* in filling the output window with crud. Please change this to do something that makes sense. What it does now doesn't. I'm sorry if this seems harsh, but this misfeature is INCREDIBLY ANNOYING!
Created attachment 13473 [details] screenshot
It was decided to have a separate output tab for every command. This is the consequence. We would have to have a single tab for all Refresh commands, perhaps. But it's not clear how it should work. Anyway, I don't think this is so annoying, because if you will not make Refresh to work, you will have bad status information and it will probably cause problems.
I understand Tim with his disapointing... a few miutes ago I verified issue #37489 related to this *misfeature* And I'm for it will be somehow solved. Martin I don't remember that before new WinSys the Refresh Output has been opened so many times ... And also that it didn't make problems with bad statuses... You've got the info about failing Refresh just into one Window/Tab...
Yes, in the old WinSys there was not this problem. There was a special "Versioning" output, where all error messages were printed. This concept was removed and was replaced with opening a separate tab for every failed command. We would need to modify the UI spec to fix this.
> It was decided to have a separate output tab for every command. This >is the consequence. Surely whoever made this decision (Jano? Dusan?) was think of *user invoked* actions, not random things VCS does in the background! > Anyway, I don't think this is so annoying, Use it for a while when your internet connection is down. You will change your mind. >because if you will not > make Refresh to work, you will have bad status information and it will >probably cause problems. I *always* have bad status information anyway! This feature is completely broken if you ever use command-line cvs for anything! I am constantly seeing things that are not on branches marked as being on branches, things that up to date marked local, etc. There are lots of ways to fix this stuff, mostly involving better heuristics: 1. You do not need to go to the server to find out if a file is modified. 2. You should be able to compare timestamps with RCS files and your cache to determine if you need to go to the server to check if something is on a branch, etc. 3. The only really interesting status is locally modified if you are just opening a directory. Up to date status should be hidden, as discussed elsewhere - it is the natural state of most files in a cvs checkout. "Needs update" is not interesting unless you want to edit a file. Don't go to the server and check that unless someone tries to *write* the file (I would say "until someone tries to *read* the file, but java prescan sources will touch them all anyway). The point is that it's far more important for VCS support to be quiet and not intrude on the user unless they ask it for something, than it is for VCS support to always display perfectly accurate information the user is not interested in 99% of the time.
Then, always set offline mode to true (it should be possible to set it just once in Tools -> Options -> Version Control Settings) and you'll be happy. Offline Refresh does exactly what you want. The problem is, that it's not possible to distinguish Up-to-date and Locally Modified status from timestapms. After you change your local time, everything would be turned to Locally Modified. One solution can be to automatically run the Offline Refresh when the regular Refresh fails. Or the VCS concept would have to be completely redesigned .... Just a note: I have absolutely no problem with status annotation and use the CVS integration regularly for development. I'm not aware of a problem with bad status information (except of occasionally conversion of any status to [Local] described at issue #32193, which is not reproducible and does not happen to me). If you have some reproducible usecases of a bad status annotation, please file an issue for it.
> After you change your local time, everything would be turned to Locally Modified. How often does that happen? > Just a note: I have absolutely no problem with status annotation and > use the CVS integration regularly for development. Probably you are not also doing commits from the command line, changing branches from the command line, etc. between restarts. Seriously, please do something about the tabs. I know you can dig into Tools | Options and find a property, but most users will never figure that out.
Tim! so far and till now I was on your side, but what you wrote: >> Just a note: I have absolutely no problem with status annotation and >> use the CVS integration regularly for development. >Probably you are not also doing commits from the command line, changing >branches from the command line, etc. between restarts. you don't mind it serriously, do you?! How do you then want reliable status information if once you use NB for CVS operations and once a different tool. By this usage you break consistence between ./CVS/Entries and ./CVS/cvscache files ... It's simmilar if you lend your car to someone and he changes all stuffs on your car (tires, breaks, etc...) for something different... and you relay on your previous state of equipment...
Well, the opening of tabs has nothing to do with how I use cvs. Typically I use netbeans CVS for graphical diffs and version browsing, and the command line to do things that will actually make modifications in the repository. > By this usage you break consistence between ./CVS/Entries and > ./CVS/cvscache files ... Why can't the cvscache file contain the last modification time of the ./CVS/Entries file, and if they don't match, it knows something has changed externally, and it can either: - 1. Go get updated information, or - 2. (better) Just go into some invalid - [?] state until I tell it to refresh - 3. (best) Figure out what it can (locally modified vs. up to date, etc.) without a trip to the server and [?] state for less useful things like if it is still on a branch, if the cache says it was before?
OK, as you said Tim >Well, the opening of tabs has nothing to do with how I use cvs. shell we move the rest of your objectives to new isssue rather to mess this one, please? the reast of your ideas are interesting and should be recorded on the right place (otherwice they'll be forgoten)
>> After you change your local time, everything would be turned to >> Locally Modified. > How often does that happen? At least twice a year when summer/winter time change. The problem with outdated cache information can be solved by some auto-correction mechanism. This was considered a long time ago, but never actually implemented. The biggest problem is, that [Locally Modified] status can not be reliably detected. See issue #31251.
>>> After you change your local time, everything would be turned to >>> Locally Modified. >> How often does that happen? > At least twice a year when summer/winter time change. I would be happy to live with cvs statii that were wrong twice a year. Anyway, you can do something about it: java.util.TimeZone.getDefault().useDaylightTime() java.util.TimeZone.getDefault().getID() java.util.TimeZone.getDefault().getDSTSavings() and see any of those have changed.
Thanks for the tip with TimeZone. This may help. TimeZone.inDaylightTime(Date) can also be useful to find out whether the time in Entries was in daylight savings time.
Raising the priority - reason: try the following: - Perform the command cvs logout - Mount a new CVS filesystem - The parser database will be updated, touching every directory in the filesystem - One output tab will open for every folder in the filesystem Now, imagine if I mounted my netbeans source root...I would have several *thousand* output tabs as a result. I don't think we can ship with this behavior.
No ideas from HIE team? A suggest to introduce a special tab for commands that fail. A single tab would be used for all failed commands like old "VCS Output".
HIE opinion: We do not suggest any UI changes now. If the logout is performed, offline mode should be set automatically.
I'd like to point to tha fact this is not anly problem of Refresh but all commands which failes: eg. Export/Import on dir structure.... if you don't fill properly command's arguments then you've got as many open tabs as are files in your dir structure...
The HIE's suggestion solves the problem only partially. It solves only a problem of Refresh and only for the case that the user explicitely log out from the IDE. The problem is, that there might be many cases in which commands fail. Intermittent connection problems, bad filesystem customization, etc. IMO the point is not to prevent the error (this can never be done completely), but provide the error message in a clean and nondisturbing way. Just my 2c.
In the VCS team it was decided, that this is not P2 priority. There is a very siple workaround - set the offline mode to true. The proper fix would require a UI change and introduction of a new feature. Due to this fact we schedule this for promotion D.
When I checked out the same as in issue #40505, proliferation of pointless output tabs occured. But I could not reproduce it.
[jglick writing here] As far as I know, the problem of daylight savings time is probably nonexistent; http://www.cvshome.org/docs/manual/cvs-1.12.6/cvs_2.html#SEC19 says "The timezone on the timestamp in CVS/Entries (local or universal) should be the same as the operating system stores for the timestamp of the file itself. For example, on Unix the file's timestamp is in universal time (UT), so the timestamp in CVS/Entries should be too. On VMS, the file's timestamp is in local time, so CVS on VMS should use local time. This rule is so that files do not appear to be modified merely because the timezone changed (for example, to or from summer time)." Of course this is completely off-topic for this report; just FYI.
Well, it would be cool if that worked. My experience is different. And not only mine (see issue #29885 where the timestamp difference after time change caused Up-to-date files to look as Locally Modified). If this is fixed in recent releases of CVS, it's good, we'd need to verify this. Thanks for your (Jesse's) comments.
Just checking in - this issue *will* be fixed for promo D, yes?
I have also faced this problem but don't know the reason why it was failing. Anyway it is really ugly and I vote for fixing this too. Maybe as a part of UI bugs fixing ?
Well, it's a UI change and thus it would have to be fixed by May 15. If there's time to do it I would like to do it. But there are still some more important issues waiting...
With apologies, raising the priority to P2. NetBeans 3.6 should not have shipped with this behavior - it's embarrassingly broken, unacceptable for any sort of professional product. This should not get by 4.0 without a well justified waiver.
O.K. We'll introduce a special "Error Messages" tab, that will be opened, or becomes activated whenever a command, which does not have already opened output, fails. The name of the failed command, it's execution string and the error message will be provided in this tab. That tab will be reused for all failed commands. It will have "Copy", "Clear Output", "Discard Output Tab" and "Discard All Output Tabs" actions.
Sounds good. <sigh of relief> FYI, I'm in the process of rewriting the output window, hopefully for promo D. It will include support for supplying toolbar actions (small toolbar on the left, if actions are supplied). So there will be a method to supply an array of Actions with icons for this, and they'll be added to the context menu as well. I'm not sure if the API for the actions will be public in D - first thing is go/no-go on the rewrite. If that happens, it could probably make this very easy for to implement. If you would like to use it, please add your voice of support to issue 43332.
Fixed as proposed. Tim, we can think about toolbar actions, but probably not into promotion D. We have still many things to do into promo-D (mainly stabilization). But it would be nice to imlpement it for some future release. /cvs/vcscore/src/org/netbeans/modules/vcscore/cmdline/UserCommandTask.java,v <-- UserCommandTask.java new revision: 1.25; previous revision: 1.24 /cvs/vcscore/src/org/netbeans/modules/vcscore/commands/CommandOutputTopComponent.java,v <-- CommandOutputTopComponent.java new revision: 1.13; previous revision: 1.12 /cvs/vcscore/src/org/netbeans/modules/vcscore/ui/Bundle.properties,v <-- Bundle.properties new revision: 1.21; previous revision: 1.20 RCS file: /cvs/vcscore/src/org/netbeans/modules/vcscore/ui/ErrorOutputPanel.form,v Checking in ui/ErrorOutputPanel.form; /cvs/vcscore/src/org/netbeans/modules/vcscore/ui/ErrorOutputPanel.form,v <-- ErrorOutputPanel.form initial revision: 1.1 RCS file: /cvs/vcscore/src/org/netbeans/modules/vcscore/ui/ErrorOutputPanel.java,v Checking in ui/ErrorOutputPanel.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/ui/ErrorOutputPanel.java,v <-- ErrorOutputPanel.java initial revision: 1.1
Also we do not set explicitly PROPERTY_IGNORE_FAIL to refresh command so that the underlying command is reported: /cvs/vcsgeneric/src/org/netbeans/modules/vcs/profiles/list/AbstractListCommand.java,v <-- AbstractListCommand.java new revision: 1.4; previous revision: 1.3 /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/list/CvsListFileCommand.java,v <-- CvsListFileCommand.java new revision: 1.3; previous revision: 1.2
Verified.