bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Maybe a bug in commit


From: Mark D. Baushke
Subject: Re: Maybe a bug in commit
Date: Sat, 18 Oct 2003 17:51:02 -0700

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rodolfo Schulz de Lima <rodolfo@rodsoft.org> writes:

> > Well, since you've mentioned that, I've a doubt, but I don't know if
> > it's a bug or not. When you try to commit a file whose only thing
> > that's changed is its timestamp, cvs doesn't do anything (even an
> > error message isn't displayed), and the file remains marked as
> > changed, i.e., CVS/Entries isn't updated to the timestamp of the
> > file in repository. You need to do a cvs update -A <filename> to
> > make the change. Is this the correct behavior, albeit a strange one?
> 
> Well, all can be resumed to:
> 
> touch test.c
> ls --full-time test.c
> cvs add test.c
> cvs commit -mTest test.c
> sleep 5s
> touch test.c
> cvs commit -mTest test.c
> ls --full-time test.c
> 
> According to what I'd expect, the last commit should change the
> timestamp of test.c to match the timestamp of the head test.c in
> repository. I made a little confusion in my last mail, CVS/Entries
> shouldn't be changed.

No, a 'cvs commit' never moves a file's timestamp back in time. Doing so
could confuse programs like 'make' that expect time to be static or move
forward for files.

I suppose it might be argued that the CVS/Entries entry for test.c
should have the timestamp updated to reflect the time of the file... 

  ls --full-time test.c
  grep test.c CVS/Entries

> The problem with the timestamps is more obvious when you use programs
> like WinCVS, which shows graphically what the changed files are. It
> compares the timestamp in CVS/Entries and the file's timestamp to see
> if the file has changed. So, after committing a file with no changes
> inside, just a timestamp change, it remains marked as changed.

Doing a 'cvs update test.c' will update the CVS/Entries file so that it
is the same as the timestamp (although in UTC rather than local time) on
the test.c file if there are no changes in the file. So, that is a
possible workaround.

In a typical case, I have never really bumped into your problem myself.
This is probably because I usually do something like:

   cvs update
   ...make sure that there were no changes to any of my files...
   ...or resolve conflicts and recompile if there were...
   cvs commit

so even if the timestamp for test.c was not right before starting the
above process, the 'cvs update' would fix it and the 'cvs commit' would
only need to commit test.c if it had real changes.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/kd/23x41pRYZE/gRAmETAJ9rb8Mlmhe3AK+B2GMDnYn0YjVccwCgmpRW
wBH4KpXCWsMRQzi2f6QHInk=
=yICu
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]