On Wed, Jul 05, 2000 at 10:01:38AM +0200, Matthias Kranz wrote:
> Ok, now I finally got your point. That the two files have
> the same timestamp is not the problem, but the fact, that
> your copying preserved the original timestamp of
> subdir1/File1.hpp.
>
> If you use a normal copy command or just edit a file, the
> new timestamp will differ to that one in CVS/Entries.
On UNIX, that is. Windows preserves the timestamp when you copy
a file (as did DOS before it, and, if I recall, as does MacOS).
The rationale is presumably that the timestamp says when the
*data* last changed, regardless of where that data happens to
reside. Which actually makes a lot of sense; to me, it's UNIX's
default behaviour that's counterintuitive (and I've been using
UNIX since long before I touched either of the others).
On Wed, Jul 05, 2000 at 04:11:10AM -0400, Leeuw, Guus (G.) wrote:
> Uhoh.... this might be because of the SAMBA link that you are using.
Much as I agree with the arguments for using CVS client/server
instead of with a remote-mounted repository, I think Samba is a
red herring in this case. The problem is due to a mismatch
between CVS's assumptions and the client O/S's file-copy
semantics, not to any mis?-configuration of CVS. Therefore:
> This, really, isn't a problem of CVS!
I beg to disagree. I've even been bitten by this once or twice
even in a pure-UNIX context (I can't remember the details, I'm
afraid.)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
[Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD
- Netcraft's "What's that site running?" service, 12-Jun-2000
