[p4] nothing better about PVCS?

[Dave Foglesong]

-----Original Message-----
From: Raymond Wiker <raymond at orion.no>
To: perforce-user at perforce.com <perforce-user at perforce.com>
Date: Sunday, January 23, 2000 11:38 PM
Subject: Re: [p4] nothing better about PVCS?


> > However, there seems to be an unnatural bias against that method.
> > It's as if someone from on high has declared that not to be the
> > best CM practice, so therefore, Perforce shouldn't support it.
> > There are other examples I've seen discussed here over the last few
> > months (not keeping the original or REAL file- dates is another
> > issue).
>
> That's also supported, by using the modtimes/nomodtimes option
>in the client spec. On the other hand, it *really* makes sense to
>let the file timestamp be the time of sync - the alternative is to
>*always* do a "make clean" after a sync.
>


Here's a case where you'd not want your SCM system to modify the file
timestamp: You want to track the contents of your installer in your source
control system. Your documentation group delivers the final help files for
your product weeks before you ship -- you don't want those files to have the
timestamp of when they were put into source control, nor the date when you
last synced them out of the system; you want them to have the timestamp when
they were last modified, which could be minutes or weeks before the files
were submitted to the system.

The timestamp issue is compounded when you have multiple products that use
shared components: If product "A" uses a component  (say, foo.dll v1.0), yet
it ships AFTER product "B", which uses foo.dll v1.1, you want to make sure
the foo.dll in the installer for product "A" has a date that is older than
the one in product "B", or a user that installs both may wind up with the
older version. (It's easy to say that the installer should have some
mechanism other than dates for detecting what version a file is on the
system, but some installers can only use the timestamp.)

Currently, the only way to do this in Perforce is to maintain a separate
tracking system of what files should have specific timestamps, and do a
touch after the sync operation. ModTime/NoModTime options in the client
don't solve this problem, since they only reflect the time the file was
submitted or synced, not the timestamp of the file before it was introduced
into the system. (The fact that these options apply to EVERY file that you
sync is also a pain; it would be nice if this was a file-by-file setting
like the file type information.)