After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 309688 - When committing a file that is loaded, I get a file-modification warning
When committing a file that is loaded, I get a file-modification warning
Status: VERIFIED FIXED
Product: anjuta
Classification: Applications
Component: core application
CVS HEAD
Other All
: Normal normal
: ---
Assigned To: Anjuta maintainers
Anjuta maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-07 08:22 UTC by Philip Van Hoof
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philip Van Hoof 2005-07-07 08:22:02 UTC
Please describe the problem:
When committing a file that is loaded (using for example cvs commit),

I get a warning in Anjuta that the file is modified and should be reloaded.
However, this ain't true. It has just been committed, not modified!


Steps to reproduce:
1. Load a project
2. Load a file that you change in Anjuta and save it
3. Go to a terminal and commit the file in a cvs repo


Actual results:
Anjuta shows a warning about the modification of the file (and asks whether or
not to reload it)

Expected results:
No such warning since the file isn't modified at all

Does this happen every time?
Yes

Other information:
Comment 1 Johannes Schmid 2005-07-07 11:00:41 UTC
Hi!

Obviously cvs touches the file when it's commited and anjuta detects this (using
gnome-vfs) and says that the file has changed because it's modification time
changed.

I don't think we can avoid this in any way because it related to the cvs command
line utility.

Maybe this is => WONTFIX

Regards,
Johannes
Comment 2 Naba Kumar 2005-07-07 11:57:08 UTC
Even if it isn't technically Anjuta's bug, it still annoys a lot. One possible
solution is to compare the content of the disk with current buffer (when we get
file modified signal) and prompt user only when there is a actual change in content.

Another related bug is that sometimes we get multiple prompts for the same file.
It usually happens when the file is being modified in steps (each modification
step triggering a signal). This can be prevented by remembering the first prompt
and avoid subsequent dialogs (a hash table can be used, for example).
Comment 3 Johannes Schmid 2005-12-14 14:08:10 UTC
Fixed bug using the new anjuta_util_diff function to create a diff between the
(maybe) changed file and the text in the editor. This should work most of the time.
Comment 4 Naba Kumar 2006-12-04 09:59:57 UTC
Closing all fixed bugs. Sorry for the mass update :( ...