On 2012-02-17 4:34 AM, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Fuhrmann Stefan (ETAS/ESA1) [mailto:Stefan.Fuhrmann_at_etas.com]
>> Sent: vrijdag 17 februari 2012 9:27
>> To: dev_at_subversion.apache.org
>> Cc: rick_at_longbowgames.com; peter_at_p12n.org
>> Subject: Re: MTime resurrected
>>
>> Peter Samuelson<peter_at_p12n.org> wrote:
>>> Now do a 'svn update' or 'svn switch' which changes foo.c.
>>>
>>> Current svn: foo.c mtime is set to the present time. It is now newer
>>> than foo.o. [Of course you can set foo.o's mtime in the future, but
>>> that's just breaking things _on purpose_.]
>>
>> Ahem. At least with 1.7+ (and probably for a long time
>> before that), a c/o or update sets ctime=atime=now
>> and mtime will be set commit time. I.e. make *will*
>> break if you update to older revisions.
>
> No, by default it does not.
>
> You only get this behavior if you enable use-commit-times in your Subversion
> configuration.
>
> Bert
Although, it *will* break if you happen to have your .o files under
version control, since it's effectively random whether the .o file or
the .c file gets touched first. Of course, programmers don't usually do
that, but there's other things you might build where you would want to
do that.
We're a game company, and we have our artists prepare all their textures
into one folder, then run a baking script that prepares the textures for
use in the game and drops them into an output folder. Because svn update
sometimes gives a newer timestamp to the input file than the output
file, our script will recompress textures that it shouldn't. This makes
svn think that textures have updated which really haven't, and it makes
our artists less likely to compress their textures in a timely fashion,
since it may take longer than it should.
I see where I went wrong when discussion build systems. (I do know how
to use make, I just had a brain fart.) What I should have said is: if
the file's text-time is <= the local file time, it uses now(), otherwise
it uses the text-time.
-Rick-
Received on 2012-02-17 10:43:08 CET