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 12914 - Some CVS Checked out java files show [Local] in Explorer
Summary: Some CVS Checked out java files show [Local] in Explorer
Status: VERIFIED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcscvs (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: issues@obsolete
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-06-16 12:48 UTC by emmanuel
Modified: 2001-07-20 20:35 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Exploere windows before and after compile (130.88 KB, image/jpeg)
2001-07-20 20:35 UTC, emmanuel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description emmanuel 2001-06-16 12:48:11 UTC
I use NB build 211.

Some CVS Repository 'checked out' java files appear in the Explorer window as 
[Local] and some with the correct revision.

Note, the previous build 206, always showed the correct 'revision numbering'.

Furthermore, when I delete all compiled class files of the 'checked out' java 
files, the revision again shows correctly.  Then, once compiled some show 
[Local] and some show the correct revision.

I'm of the opinion that this is critical misinformation.  Could this be 
corrected please.

Kind regards
Emmanuel
Comment 1 emmanuel 2001-06-16 13:07:54 UTC
After switching to another project and back or stopping & starting NB, 
different files show [Local] and the correct revision.
Comment 2 Jiri Kovalsky 2001-06-18 12:51:25 UTC
Emmanuel, although I understand your frustration about this behaviour I must 
lower the priority since this is not true showstopper either for IDE that is 
defined as freezing or data lost or VCS modules that prevents you from any 
version control functionality.
Of course we will do our best to fix it as soon as possible but P1 would define-
tely mess up bugs statistic. If you want you can vote for this bug that will in 
fact increase its virtual priority.

As for the issue itself:
1. Do you have any reproducable case ? (I am not successfull with .class files)
2. Are you sure you used CVS Command-line Client or Built-in Client ?
3. Don't you have "Process All Files" property of CVS filesystem turned on ?
Comment 3 emmanuel 2001-06-18 20:22:46 UTC
Hello Jiri, Thank you for your assistance, and;

>Of course we will do our best to fix it as soon as possible but P1 would
>definetely mess up bugs statistic.   If you want you can vote for this bug
>that will in fact increase its virtual priority.

No problem, point taken and thank you.

>1. Do you have any reproducable case ? (I am not successfull with .class files)

Happens every time.  Not sure what you mean here with .class files.  Build 206 
worked fine, now with build 211, some CVS checked out .java files do not have 
the correct CVS revision numbering.  When I delete the associated .class files 
which I have in a different (target) directory, the CVS revision numbering 
appears correctly after 'refresh'.  Then once I compile the .java files, 
some .java files' CVS revisions appear correctly, other .java files appear as 
[Local] even though they are CVS checked out.  The CVS revision numbers for 
file types .txt .xml .html always appear correctly (I suspect due to the fact 
that they do not compile as .class files).  It seems as if during the 
determination of the .java CVS revision, the state of .class files are also 
brought into the equasion - at that point something goes awry.

> 2. Are you sure you used CVS Command-line Client or Built-in Client ?

I use NB CVS command-line client (I think), viz., "cvs.exe".

> 3. Don't you have "Process All Files" property of CVS filesystem turned on ?

I have no idea what this is for, but I checked and this value is set to 'false'

Hope above sheds some light.

Kind regards
Emmanuel
Comment 4 emmanuel 2001-06-18 20:36:17 UTC
Created attachment 1631 [details]
Exploere windows before and after compile
Comment 5 Martin Entlicher 2001-06-19 13:46:14 UTC
Emmanuel, thanks for your detailed description. It helped me to locate the
problem. I've fixed it in the main trunk, the fix will appear in dev build #213.
Comment 6 Martin Entlicher 2001-06-19 13:52:30 UTC
I forgot, that the build numbering has changed. The fix will appear in build
#200106200100.
Comment 7 Jiri Kovalsky 2001-06-19 14:19:39 UTC
Good job Martin and Emmanuel ! Especially your note about different target 
directory turned out to be essential :) so I would like to ask you if you could 
verify that it works for you in tomorrow's build and if so change the status to 
VERIFIED ? Thanks a lot !
Comment 8 emmanuel 2001-06-20 20:18:21 UTC
Hello Jiri,
>Good job Martin and Emmanuel ! Especially your note about different target
>directory turned out to be essential :)

You're welcome.

>so I would like to ask you if you could verify that it works for you in 
>tomorrow's build and if so change the status to VERIFIED ? Thanks a lot !

Its great, and back to 'normal', it works 100%, thank you to the developer and 
everyone involved.

Kind regards
Emmanuel