WAD.
please use 'show changes' to refresh the VCS status cache when invoking VCS commands externally.

My point was that it should do this automatically. Most other IDEs periodically check files on frame activation and
update the display for you. NetBeans should do the same. Having to constantly click something is a productivity loss and
annoying.

1.) 
netbeans checks the filesystem for changes. There are some limitations (i'm not going to discuss at this point as that
would be a bit out of scope), but the crucial thing here is the fact that the commit doesn't change a files timestamp so
there is at least in some (probably most) cases no change notification intercepted in the svn plugin and having the VCS
modules to scan all known files/working copies for possible status changes would definitely be a performance killer.
 
2.) 
why don't you use the netbeans commit anyway? In case it shouldn't meet your needs, please don't hesitate and file an
enhencement

3.) 
> Most other IDEs periodically check files on frame activation and
> update the display for you.
i gave one of them a try and it didn't work either...

4.) 
again. this is WAD. closing as wontfix this time. seems more appropriate than invalid
 

>1.) 
>netbeans checks the filesystem for changes. There are some limitations (i'm not going to discuss at this point as 
>that would be a bit out of scope), but the crucial thing here is the fact that the commit doesn't change a files
>timestamp so there is at least in some (probably most) cases no change notification intercepted in the svn plugin 
>and having the VCS modules to scan all known files/working copies for possible status changes would definitely be
>a performance killer.

The SVN client and working directory understands this information quite well. If you look at IntelliJ, it handles this
just fine with no loss of performance. You might consider looking at the SVNKit tool as that is what they use and it
might help in this situation.
 
>2.) 
>why don't you use the netbeans commit anyway? In case it shouldn't meet your needs, please don't hesitate and file 
>an enhencement

I perform tests, and a number of other operations before a check in. I much prefer the command line for this work and
find that I am much more productive than in an IDE. I also use other tools that might touch the SVN working copy.
Constraining uses to only the IDE is a dangerous plan and large productivity loss. This is one of the huge strengths of
IntelliJ IDEA.


>3.) 
>> Most other IDEs periodically check files on frame activation and
>> update the display for you.
>i gave one of them a try and it didn't work either...

IntelliJ IDEA does this. You obviously didn't check that IDE. I base most of my bugs for NetBeans against IDEA.


>4.) 
>again. this is WAD. closing as wontfix this time. seems more appropriate than invalid

Your choice, but this is definitely an issue that others have solved and I feel it is important for NetBeans to fix it.
I won't re-open it because I'm certain you'll just close it. But I think you should look at the overall productivity of
NetBeans versus IntelliJ IDEA and you'll see many problems, including this one.

I did some more research into IntelliJ's support for this and I'm going to re-open this issue for further discussion.
IntelliJ updates all files in the project in less than a second on frame activation. I had a project where I modified,
added, moved or deleted 40 files and then performed a commit via the command-line. When I switched back to IntelliJ, it
was able to change the status of all of these files immediately on frame activation.

I also played around with the SubVersion command-line tool and it works the same way that IntelliJ does. If you touch
files in your project like this:

'touch build.xml'

SubVersion does not mark them as modified when you execute 'svn status'. I'm guessing that it uses a hash or a fast
binary diff function to handle this. In addition, the SubVersion command-line tool is capable of checking very large
projects without much overhead.

I'm sure NetBeans can figure out how to do this and I feel that this issue is valid. Again, the SVNKit tools allow you
access to the SubVersion working copy directories and perform the same tasks as the command-line tool. I think you could
probably handle this using that library or looking at how they are doing it.

I also forgot to mention that using the work-around you can in comment #2 doesn't work.

I hit the "Show Changes" menu item from the "Versioning" menu and it did not update the status of the files in the
"Project" browser or the "Files" browser. They still are colored blue for modified and green for new.

It appears that you need to use the action "Subversion -> Show Changes" located in the context menu of the current
project in the "Files" browser to get NetBeans to update its cache. The same action from the "Versioning" menu doesn't
really do anything.

"Show Changes" action is context sensitive with no regards whether it's been invoked as a popup menu action or from main
menu. It processes the context that is selected (or in a case of "Versioning" window - the context that was selected
while "Show Changes" was run)  

I see. That makes some sense, but is also confusing as it isn't apparent to a newcomer that the IDE works in this
fashion. Even still, my currently selected project was the one in question and therefore the menu item should have still
worked properly and it didn't.

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

I marked 170061 as a duplicate of this issue. It was a different problem, but along the same lines. The issue I have NetBeans is that it pretends that the 
command-line and SubVersion working copy don't exist. When you add a new file or class in NetBeans, it should at least ask you if you want to add the file 
to SubVersion. If you answer yes, it should add the file to the working copy. Currently, it does neither.

In addition, the original issue of this bug is still valid. Requiring that developers invoke an action to refresh the IDE is very cumbersome and slow. It is also 
not really necessary with the speed of modern computers and how efficient the modern JDKs are with respect to threading and files. You should be easily 
capable of looking in the SubVersion working copy directories on frame activation to determine if a files SubVersion status has changed.

I suggested on bug 170061 that you guys use svnkit because it works fine and this is what IntelliJ uses. I'd suggest that you serious investigate solving this 
issue as other IDEs are making developers lives simpler with these types of features while NetBeans is still very cumbersome and clunky with keeping the 
project in sync with the outside world.

Sometimes the you need to submmit to subversion stuff that is not code. For example I have the following structure in most of my projects:

Top Folder
-DB
-Documentation
-Project 1
-Project 2
.
.
.

Netbeans only sees code within the porjects it can open but not the rest of the folder. Because of that sometimes I need to use Subversion client to commit the rest. If on that "external" commit I also commit stuff within the projects that's when the update doesn't happen within the IDE.

*** Bug 207806 has been marked as a duplicate of this bug. ***

We won't support external commits and other changes to the WC. In that case refresh the files using Subversion -> Show Changes