Re: CVS Best Practices

[gabriel rosenkoetter]

I'll actually read this when I get a chance (this is a busy couple
of weeks), but just at a glance... in response to section 4.1, yes,
CVS can definitely handle developers in separate time zones. That's
why output from (say) date(1) is tagged with a time zone at all, so
that the correct math can be done by Unix (well, POSIX-compliant)
machines in separate time zones. What's more, the date that matters
is the time on the server, and it's only in one time zone.

Even if you've got a checked out sandbox, as long as you're on an OS
with a sane handling of time zones, this is not a problem.

That is, here's a file with my time zone set to Eastern (that is,
/etc/localtime on my NetBSD system is a sym link to
/usr/share/zoneinfo/Eastern):

-rwx------  1 gr  users     3293 Nov 16 09:11 essay2.tex*

The same file with the time zone changed to Pacific:

-rwx------  1 gr  users  3293 Nov 16 06:11 essay2.tex*

Note that I didn't read from or write to this file in that time, nor
did I use touch.

ctime and mtime are stored in seconds since the epoch and
translated, by software with access to what time zone the machine
presently lives in (which software includes CVS) into date format.

-- 
       ~ g r @ eclipsed.net

pgpTowipdcpg9.pgp
Description: PGP signature