|Summary:||cvs diff/commit fails when timestamp of file is (almost) the same|
|Product:||[Fedora] Fedora||Reporter:||Robert de Vries <rhdv>|
|Component:||cvs||Assignee:||Jiri Moskovcak <jmoskovc>|
|Status:||CLOSED CANTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-10-01 08:38:17 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Robert de Vries 2007-07-17 21:06:39 UTC
Description of problem: cvs diff, commit does not detect change if timestamp is too close to original timestamp. Version-Release number of selected component (if applicable): cvs-1.11.22-9.1.fc7 How reproducible: always Steps to Reproduce: See script Create a file, commit, modify again, show diff (but do this fast, i.e. using the script) Actual results: No difference shown Expected results: Difference shown Additional info:
Comment 1 Robert de Vries 2007-07-17 21:06:39 UTC
Created attachment 159474 [details] Procedure to reproduce bug
Comment 2 Jiri Moskovcak 2007-07-18 09:22:21 UTC
Hi, I tried to reproduce this bug, but with no succes - I always get the right diff output. Did you use repository on local or remote machine?
Comment 3 Robert de Vries 2007-07-18 17:49:08 UTC
I use a local repository in /tmp (not that the exact location matters). CVSROOT=/tmp/test-cvsroot When I add a sleep(1) between the steps, it works again. It shows the diff, proceeds with the commit.
Comment 4 Jiri Moskovcak 2007-07-19 13:51:44 UTC
I'm really not able to reproduce the bug, I've tried to on 3 different machines and always with the same result - right diff output with or without sleep(1) in your testing script.
Comment 5 Robert de Vries 2007-07-22 12:29:16 UTC
Weird, I can easily reproduce it. Are you using the same cvs version? Mine is cvs-1.11.22-9.1.fc7 I have not seen this problem in any of the previous cvs versions on any of the previous Fedora Cores (not 100% sure that any of the cvs packages in updates have the same problem).
Comment 6 Jiri Moskovcak 2007-07-23 07:51:13 UTC
Yes, I'm using the same version (cvs-1.11.22-9.1.fc7) on F7 and it seems to work fine. Here is the output from your testing script: (both diffs show the changes) Checking in x; /tmp/test-cvsroot/x,v <-- x new revision: 1.3; previous revision: 1.2 done expected diff output here, but there is none Index: x =================================================================== RCS file: /tmp/test-cvsroot/x,v retrieving revision 1.3 diff -u -r1.3 x --- x 23 Jul 2007 05:45:25 -0000 1.3 +++ x 23 Jul 2007 05:45:26 -0000 @@ -1,3 +1,4 @@ foo bar bar +bar now there is diff output Index: x =================================================================== RCS file: /tmp/test-cvsroot/x,v retrieving revision 1.3 diff -u -r1.3 x --- x 23 Jul 2007 05:45:25 -0000 1.3 +++ x 23 Jul 2007 05:45:27 -0000 @@ -1,3 +1,4 @@ foo bar bar +bar
Comment 7 Robert de Vries 2007-07-23 11:01:35 UTC
I have compared the source packages of the cvs for fc6 and f7 and I did not notice any changes in the source code, except that cvs is now kerberized. However I do not think that that should have any influence on the behaviour of cvs in this case. Another difference that might be relevant is external to cvs and that could be glibc or the kernel. I am currently investigating into that direction, but I would like to know which version of the kernel and glibc you are using so that I can compare with my set-up. I am now running the latest and greatest packages (I ran yum update yesterday).
Comment 8 Jiri Moskovcak 2007-07-24 07:22:25 UTC
Hi, I'm using: kernel 2.6.21-1.3194.fc7 and glibc-2.6-3.
Comment 9 Jiri Moskovcak 2007-08-09 10:34:50 UTC
Hi, any progress in your investigation?
Comment 10 Robert de Vries 2007-08-09 18:56:37 UTC
Sorry I haven't had the time to figure this one out. Now I'm going on a three week holiday so you won't hear from me until september. I'll bring my laptop with me on holiday and maybe I'll have some time to spend on this. (big maybe)
Comment 11 Jiri Moskovcak 2007-10-01 08:38:17 UTC
I'm not able to reproduce this bug, it works for me.