On Sun, 2004-03-28 at 14:21, Ralf.Bauer-Malz@etas.de wrote:
>> Why would you have expected that? (Genuine question.)
>
> I expect it as documents should not be changed in any means by a CM
> system.
Well, that's clearly not the case. The ownership of files in your
working copy must (in general) be different from the ownership in other
working copies. The ctime (inode change time) is necessarily going to
be different. If you've requested keyword or newline translation, those
things are going to be different as well.
> I expected it, too , because other CM software I used before (e.g.
> ClearCase) behaved like this.
Aha. Clearcase has its own specialized "make" equivalent which doesn't
need to rely solely on mod times to figure out what needs to be
rebuilt. Since Subversion doesn't have that (and doesn't want that), we
are somewhat more constrained in our options for default mod time
behavior.
>> Why is this annoying? (Also genuine question.)
>
> Maybe this is just a communicatiuon problem. We used to talk about a
> document to change and referred to the file change date. With SVN we
> must use version numbers.
Okay, so you need consisted times for files modified by "update" as well
as for files which have been checked out. (This has some bearing on the
arguments we had over the correct timestamp behavior in the past.)
As Ben pointed out, you can set the use-commit-times option to get what
you want, at the expense of having to be a little more careful if you
use "make".
> For delivered (i.e. exported) documents the file date must be ignored
> when diffing later or on another machine.
> Our compare tool sets time comparison by default.
"svn export" always uses the commit time as the mod time, so you should
have no problem there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 28 21:46:09 2004