| Summary: | CVS commits causes KDevelop to display the file as being edited from outside | ||
|---|---|---|---|
| Product: | [Developer tools] kdevplatform | Reporter: | Simon Ejsing <simon> |
| Component: | cvs | Assignee: | KDevelop Developers <kdevelop-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | esigra |
| Priority: | NOR | ||
| Version: | 0.9.94 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Simon Ejsing
2004-02-18 13:47:49 UTC
> 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 |