Community
Participate
Working Groups
Build ID: M20060921-0945 Steps To Reproduce: 1. Create a new file test.txt in a shared project 2. Add test.txt to .cvsignore (.cvsignore will be created) 3. Add .cvsignore to .cvsignore .cvsignore now has content: test.txt .cvsignore Although there are no changes to commit in the shared project, the project will be marked as dirty (>) in the Navigator view. For illustration please see http://hnsp.inf-bb.uni-jena.de/ukuester/EclipseCVSDecoratorBug.jpg The folder Lebenslauf doesn't contain any changes, which I double checked by synchronizing it (see Synchronize view in the down left corner), yet it is marked as dirty after I did the steps listed above. The same problem happened to me, when I globally ignored all files Thumbs.db. Folder containing such files where still marked dirty although they didn't contain any commitable changes.
I was able to reproduce this but also noticed that, after a while, the problem fixed itself. This leads me to believe that the problem may be that the dirty state reset is not properly get sent to the parent of the resource that become ignored.
Michael, could you give me any suggestions where to search for the bug cause?
This is actually a fairly complex area. I would suggest you put a breakpoint in EclipseSynchronizer.adjustDirtyStateRecursively and see what happens when you dirty a file. By stepping through the code, you should get an idea of what is going on. To summarize, when a file is changed, we set the dirty state to RECOMPUTE. Then, when the dirty state is requested, we either return the cached state or recalculate it if the state is RECOMPUTE.
this method is not called when ignoring .cvsignore. I welcome any other hints.
Interesting. Perhaps that is the problem. Try EclipseSynchronizer#ignoreFilesChanged. This should trigger a recalculation of the dirty state of the parent folders but perhaps it is not.
Michael, ignoreFilesChanged is not called, neither. Maybe you have any suspicions? What is the difference between regular file and .cvsignore?
OK. It looks like a call to EclipseSynchronizer#addIgnores doesn't result in a call to those methods (i.e. EclipseSynchronizer#addIgnores is called indirectly from the IgnoreAction). I guess that explains what the problem is. The call is generating events in the decorator and subscriber but is not setting the dirty state of the parent folders to recompute.
Micheal, I have found the cause - look at the flow of ignoring resource: 1. Resource is ignored. (Added to .cvsignore). 2. Some events are propagated (we do not care). 3. POST_CHANGE resourceModified event is generated in separate thread (this one is resposible for adjusting dirty state). 4. The event is ignored, because .cvsignore is now ignored. No update of dirty state. I do not see any solution for this except forcing full refresh of the three after .cvsignore modification. Am I missing something?
In step 3, could you add an explicit check to see if it is the .cvsignore that has changed and, if so, still process it (i.e. never ignore a change to .cvsignore even if the file is ignored)?
I have tried to do so, but then ignoring other files fails if .cvsignore is ignored. I think this is because of assumption that modified file is always dirty. But I have not verified that.
Created attachment 66843 [details] Fix The solution is cleaning the .cvsignore state and its path after change manually if it is ignored.
Patch reviewed and release to HEAD. I did make one modification. Instead of marking the parent folders as clean to trigger the decorator refresh, I just added the file to the list of modifiedResources. This triggers a redecoration of the file and it's parent folders.
