This also happened to me a couple of times with different builds on Mac OS X. It broke a couple of builds for me, which is bad for me and bad for the team.

I've actually seen this happen where I'll make a bunch of changes, then immediately commit. After I commit, a period of 15 seconds or so will pass, and then all the sudden, I have a few more files in my changes list that need to be committed. It's like there is a delay when finding changed files to commit so you end up commiting only a partial list of recently changed files.

Grant, I usually even synchronize manually before invoking Commit due to all those missed move-operations.

Hello Yann,

1) could you please check (in Changes | Repository or by svn log) whether those two files had actually been committed?
Could you also check (if they were committed) - were there any changes to them? (through Diff)

and were there any changes comitted in your second commit?

2)
Do you use "Update administrative information only in changed subtrees" option in Update project?

1) there was no second tried commit on server, and IIRC all files were included correctly in first big commit
2) yes (btw, there's no help entry for this option, only tooltip), also "run status after update" is disabled

If it is not too difficult for you, could you please do the check with
"svn log <local path> -r <revision number>"
OR
in Changes | Repository -> your revision from list -> details on the right

it is important to understand where the bug was.

it is the only thing we still could check - the local state had changed and we can not now check local status...


Concerning "Update administrative information only in changed subtrees" - this option is intended to make updates faster, and it uses another algorithm for work with Subversion administrative information. It makes fewer locks in administrative area.

what do you mean with "details on the right" - the list of changed files? as I wrote I'm quite sure all files which I committed first are shown there

I see, sorry. I misunderstood you.

Yann,

Did the blue status stay only on the files that you have renamed?

IIRC yes

maybe it helps- what I did was the following:

1. rename SomeClass –> SomeClassImpl
2. extract Interface to SomeClass-interface, so basically "overwriting" previous Class-file

note: interface was created in different module, but with exactly same path-structure

Irina –

Here is another example in SVN_refresh.jpg.

For example, I made some changes to JAR files in my project and at first my IPR file (rocheCWP.ipr was highlighted as modified). Then I made a couple more changes to other files, and then all the sudden IDEA thinks that RocheCWP.ipr is no longer modified. Using an external tool like tortoiseSVN, you'll see that it indeed is modified. I can even do a diff on the file using tortoise and I see all my changes that IDEA is not detecting.

Interestingly, if I right click on the file in IDEA and compare to latest version from HEAD, I'll see all my outgoing changes highlighted. For some reason IDEA just isn't recognizing them so it's not in any changelist to be
committed. This is one situation that happens quite frequently where IDEA doesn't find changed files.

This test was done in 8.0 RC2

Grant

Also, the pom.xml file circled in the screenshot is modified yet IDEA doesn't think it is.. The only way I'd remember to check it in is to minimize IDEA and use TortoiseSVN.

Grant,

Please don't confuse things by piling unrelated reports into one issue. I see that you're having problems with files which are in the project base directory but outside of any module content roots. Please file a separate issue about this.

Dmitry –

Sorry about confusing things. I'll go ahead and file another issue. I thought since both were about refreshing the status they were the same.

Grant

(fixed by Maxim Shafirov)