[Top][All Lists]

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

Re: cvs up slowdown

From: Mark D. Baushke
Subject: Re: cvs up slowdown
Date: Tue, 19 Sep 2006 14:31:12 -0700

Hash: SHA1

James Cloos <address@hidden> writes:

> >>>>> "Mark" == Mark D Baushke <address@hidden> writes:
> >> From a read of the src, it looks like is is supposed to do that only
> >> for locally-modified files.  I cannot see why it should think the
> >> files were modified, though....
> Mark> This can happen when the timestamp on the file is different than the
> Mark> timestamp in the CVS/Entries file which in turn can happen if your
> Mark> tree is using NFS storage on a machine that has a different concept of
> Mark> time than your local machine.
> Looks like the problem stems from the use of a right/... timezone
> instead of a posix/... timezone.  The UTC-vs-posix difference skewed
> the seconds of the timestamp in Entries.

The timezone in use is UTC. That is, it uses strftime() to convert the
st_mtime of the file into a string which is written into the CVS/Entries
file. It intentionally does not bother with a timezone as the file is an
internal data structure always maintained in UTC. The time is only
written to one second of granularity. This can cause problems with a
system that can checkout and modify a file all within the same second
which is typically why a cvs client waits until the next second before
finishing its operation.

If the local disk is on a subsystem that maintains its own time, then
that could be a problem as CVS assumes that the filesystem time and the
current computer time are consistent.

> In short, cvs's idea of GMT when using a right/... timezone is wrong.
> It only changes the hours, not also the seconds.

I have no idea what you are talking about here.

> I'll look at it some more and submit a patch.
> It there an easy way to fix the Entries files, to have them match the
> files' timestamps?

Sure. Use a local filesystem and you won't have a problem. Use an NFS
mounted filesytem and ensure that everyone uses a consistent timestamp
that is within 500 milliseconds of the same time and you should be fine.
If you see that the time on your filesystem is more than 10 milliseconds
different from your computer time, then you have other problems that
will bite you if you ever try to use tools like 'make' on those files in
any case.

        -- Mark
Version: GnuPG v1.4.4 (FreeBSD)


reply via email to

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