I don't believe it. It works perfectly for me. Do you use Command-line
or Built-in client ? Is this 100% reproducable ?

I use external cvs client over ssh on netbeans 200207230200 under
Linux. I did it again after restarting netbeans and do it again.

Java:
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

Changing version to 4.0 dev. 200207230200 is a development build, not
release34 build.
We were able to reproduce it in development builds, I'm searching the
source of the problem.

Changing the bug SUMMARY to better describe situation (I hope:)
from:
     Explorer does not update after commit
to:
     Nodes in Explorer are not updated -> so filestatuses remain
"default" while iconbudgeing and tooltips are OK

Please correct it if you have better ide.
     

Well, it happend me several times also on NB3.4 version, so 
I'm also changing the version (even thought I don't have any
repro-procedure).


Also it is not UI subcomponent, do you agree?

In development builds this happens much more frequently. It can be
reproduced after a while.
The icon badging is correct and also the node's tooltip gives the
correctly annotated name. But the actual annotation is [Local].

IMHO it's a bug in DataNode, but I'm not 100% sure.
Moving to openide, please try to reproduce and make sure, that the
annotation is correctly refreshed after the FileStatusEvent is fired.
Thanks.

Anyway this does not seem to be bound to nodes. It is more likely 
DataSystems problem. 

For me it's still happen me quiet often on NB3.4 RC1.
I created a screenshot for you;-)

Meaybe some PATH/JAR with debug messages could be usefull if you
aren't able to reproduce it easy.

Created attachment 6945 [details]
Correct Tooltip but Bad node's string representation (status is [Local])

*** Issue 26109 has been marked as a duplicate of this issue. ***

This is very annoying issue and definetely deserves higher priority.
Also three votes show that it's rather serious.

The bug is serious for dev builds, but it can't be 
considered as P2 for NetBeans 3.4.

I am going to investigate it in both versions - 3.4 and 
4.0dev, but I am changing the version back to "4.0 dev"

*** Issue 26386 has been marked as a duplicate of this issue. ***

It's very strange. I opened the version explorer and made commit then
there were update of version in version explorer but no change in
normal explorer :(

Yes. The Versioning Explorer is implemented in VCS modules and thus
should provide always the correct status information unless there is a
bug in VCS modules.

I'm interested about progress of the fix. Is it on the way?
This bug is realy anoying and more, it leads to desinformation:-( And
lasts there almost for 1 month.
Could we increase the priority to be fix ASAP,please?
And also target Milestone to the 4.0Release, at least?

I had to HACK module validation tests because of this bug, to they
could pass. And this hack simply doesn't care about file's statuses
which is very very bad:-( And it is simply like this JavaCVS
Validation test doesn't exist or hasn't been run:-(

You could look into current QA test Results of DEV build...and see
logs starting addTest() suite...
http://ffjqa.czech/automatedtests/xtest/netbeans_dev/200208230100/qa-functional/qa-fiji.czech/index.html
http://ffjqa.czech/automatedtests/xtest/netbeans_dev/200208230100/qa-functional/qa-fiji.czech/testrun_020823-123101/testbag_21/user/validation/JavaCVSValidationTest/testAdd/testAdd.log

or simply see JavaCVSValidation.java in module javacvs/tests....

grrr... :-( I forgot to CC' Martin

hmmm... and seems that we should change the guy to whow is this bug
assigned:-(...

Sorry, mistakenly touched this bug.

dstrupl, after you return from vacation early next week please fix
this bug.  QA marked it as future Q stopper.  Thanks

Some more notes about how the bug can be reproduced for David:
Even if the status information is correct after the filesystem is
mounted or after refresh, the bug can be reproduced by a modification
of an Up-to-date file.
1) Add a space somewhere to the file and save it. The file probably
change to [Locally Modified]. If not, it's this bug.
2) Undo the change, save and perform CVS -> Refresh on that file.
3) The icon badge change correctly, but the file stays [Locally
Modified].
4) Close the file in the Editor and open again. You'll see
[Up-to-date] file in the editor tab, but [Locally Modified] in the
Explorer.

I have verified that the culprit is DataNode. If I revert the DataNode
to version 1.71 (the one used in release34) the problem disappears. So
now I am checking which commit (between 1.71 and 1.74) caused the
regression. 

Ok - my fix of #19608 caused this regression. I will rollback the fix
(and reopen #19608 ;-( ). 

Fixed by rollbacking the diff for #19608. DataNode 1.75.

Yeah....In current dev builds it is OK now!
Thanks

Does this issue happen in 3.4?
Daniel Mladek, you said you saw this on 3.4RC1, is this reproducible
on 3.4final?

working on it...

Well, simply I can't reproduce it on NB3.4FCS (build #200208222340)
neither with clear settings nor old ones. The reproduction (on NB3.4)
for me hasn't been so easy and reliable  as it used to be on certain
NB4.0dev builds.

I don't realy remember why it used to happen me with NB3.4dev or RC

So answer to your question Maxim is:
NO, it doesn't happen on NB3.4 :-)
    ...and as the evidence could be taken reverted fix of the
    DataNode to version 1.71 (the one used in release34-where
    this problem doesn't occure)


(and if it somehow occured, probably it couldn't be fixed by this
integration of this bugfix)

OK,
this will NOT come into 3.4.1

The fix is not needed in 3.4.1 - the bug was caused by a mistake after
release34 was branched (in trunk).

I'm experiencing this problem with 3.6rc1.
The repro-case from
"Additional Comments From Martin Entlicher 2002-09-02 08:56 PDT "
fails at step 1. 

Michal , 
this is very very old issue , maybe it's the same , but it will be
better if you 
FILE NEW SEPARATE ISSUE .....

I don't think it's the same issue - maybe the same steps to reproduce
but not the same issue ....

BTW: this issue is P1 and not updated status in the explorer isn't
high priority issue ....

FIXED long time ago

verified

This issue had *1 votes* before move to platform component