Version: 3.0.0 (using KDE KDE 3.2.0) Installed from: Gentoo Packages Compiler: gcc (GCC) 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7) OS: Linux When I commit a file in KDevelop using the CVS menu (right-click -> CVS -> Commit) the file is commited as it should be, but afterwards the file I'm editing always shows up as edited from outside KDevelop (the disk icon on the tab is showing). Pressing F5 (reload) is the only way to make the icon go away, but it causes KDevelop to display a warning dialog about loosing data. A CVS commit does not change the file contents, so this shouldn't be neccesary? I'm thinking it might be caused because KDevelop uses the last accessed time instead of the modified time of the file? This seems to be correct as the bug is reproducable by just copying a file opened within KDevelop to eg. /tmp/test.php To reproduce: - Open a file within KDevelop - Open a terminale - cd to directory of the opened file - cp the file to /tmp - Press reload (F5) within KDevelop
> A CVS commit does not change the file contents. This IS false. A CVS commit changes the file contents. >so this shouldn't be neccesary? It is necessary. The solution seams to do an automatic reload in such situations. BUT you may loose data.
Why would a CVS commit change the file? Anyway, a "cp" shouldn't, and it results in the same behaviour...
Yes, the 'cp' behaviour is clearly wrong. I've fixed it here, just need to do some more testing. Will commit shortly.
Simon, what filesystem are you using? I can reproduce the 'cp' behaviour on reiserfs. Ian, who is on ext3, cannot.
reiserfs
Try to add a "$VERSION: $" string somewhere in the file and you will see how a file changes with a CVS commit!
Okay, I'll take your word for it that CVS commit changes the file, however when I CVS commit, my changes should-be / are automaticly saved, so even if the file is modified by CVS commit it should be fairly safe to reload it, right?
Yes, like I said it sould be safe to reload after doing a commit, and it can even be done automaticaty if : The commit operation saves the file using kdevelop, then does the commit, waits (blocks the IDE) until it gets the result of the commit reloads the file. The problems are: -Remote repositories can take a significant amoutnt of time to return. -If you have modifications that you do not want to commit, then bad luck because the IDE saves the file without asking you.
This turns out to be far more complicated to fix than I first thought. The problem is also getting worse for some cases, after some recent changes to katepart.
> The commit operation saves the file using kdevelop, > then does the commit, waits (blocks the IDE) until it > gets the result of the commit reloads the file. Why should we? We have other places where we execute asynchornous operations that could mess up even more. i.e. who the hell keeps the user from changing (and saving!) files while make is running? IF we make cvs commit a synchronous operation, we most probably should make MUCH other stuff synchronous too! Like: - starting KDevelop ( some things really screw up, if kdevelop is still loading ) - initial C/C++ project parsing ( some things really screw up, if kdevelop is still parsing ) - running configure - running build operation - running a "clean" operation - running a vcs update operation - probably more... > The problems are: > -Remote repositories can take a significant amoutnt of time to return. We have a wonderful signal/slot system - and i know we are notified when compilation is done, so i assume we can do that for any KProccess we're calling, right? >-If you have modifications that you do not want to commit, then bad luck > because the IDE saves the file without asking you. Every IDE - i know of does - this. If i tell the IDE to commit, it commits. Nothing else would i expect :-) Just to add more than my ususal 2 cent... MSVC interactively asks me what to do with a file as soon as it has been changed externally. I remember kate/kdevelop doing that at some time too, but that's has vanished meanwhile. Cheers Sascha
From a users point of view it's damn annoying to have to deal with reloading the file everytime you've done a CVS commit (especially because I didn't have to in previous versions of KDevelop), and that's for every file your commit affected, that's the reason I submitted this bug report.
Sascha, just for the record, I'm happy with the current situation. I was just trying to explain Simon the problems that changing the current way of working would bring. :)
as far as I can see this is fixed