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.
[nb4.0 beta 2 build, win XP] After merging some sources from a branch to trunk the cvs window showing a table with particullar merged files do not show some file names and paths (see attached screenshot). The text output of the cvs command is also attached (it's correct).
Created attachment 19169 [details] CVS update command log
Created attachment 19170 [details] The ide screensthot
Moreover, the merged files statuses was wrong after the update(merge). All changed files had up-to-date status - I had to refresh the folder and then the files appeared as locally modified.
The problem seems to be that there are missing U or M responses for the affected files. On Windows there is a problem that we can not take the information from the error output, because it's not in synch with standard output. The workaround that is used to guess the file path does not seem to work in this case.
On JRE 5.0 there is ProcessBuilder.redirectErrorStream(true). Let's call it using reflection. Most users runs on JRE 5.0 anyway.
Fixed in trunk: /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/config/cvs.xml,v <-- cvs.xml new revision: 1.142; previous revision: 1.141 done Processing log script arguments... More commits to come... Checking in cvsprofiles/visualizers/update/CvsUpdateVisualizer.java; /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/visualizers/update/CvsUpdateVisualizer.java,v <-- CvsUpdateVisualizer.java new revision: 1.21; previous revision: 1.20 done Removing cvsprofiles/visualizers/update/CvsUpdateVisualizerStdOut.java; /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/visualizers/update/CvsUpdateVisualizerStdOut.java,v <-- CvsUpdateVisualizerStdOut.java new revision: delete; previous revision: 1.6
It looks that this fix might not be reliable in all cases due to unreliable merging of error streams. See issue #55594, issue #55958 and issue #35999. Reopening, we'll likely need to rewrite that....
After issue #55958 was fixed, it should behave correctly with the built-in client. If it does not get the Examining messages, it uses a workaround to guess the file paths, so it should work O.K. in most cases now.