Mark Reibert wrote:
> I am always a bit suspicious when people request this "feature". At
> least if you are managing compilable software this seems to
> be, in fact,
> quite undesirable. Let's say I have a WC based on r5, and it is
> successfully compiled. Then I want to see how things change
> if I back up
> to r4 of foo.c. So I type "svn co -r4 foo.c && make". If my tool
> preserves timestamps then foo does not get rebuilt. Doh!
This is a shortcoming of make. The make program makes assumptions
that cannot in general be expected to hold. If make actually worked
as advertised, then "make clean" would never be necessary except to
save disk space.
make relies on the file modification time, which is a datum that any
program can programmatically change at any time to any value for any
reason. Like, for example, Subversion does! The optional setting
mtime to last commit time will already mess with make just as much as
restoring the original mtime would.
Even without programmatic change, make can be confused. Here's just
one example: If you ever commit a build artifact, then make is in
trouble because accidents of the checkout/update order determine
whether the build artifact appears up-to-date or not. (Incidentally,
restoring mtime would /fix/ this particular scenario, at least
partially.)
make is well-known and ubiquitus, and you may choose to use it anyway.
But if the shortcomings of make bother you, don't try to mold the rest
of the world to fit the flaws of make - switch to a better build
system instead. Like one that uses file checksums instead of timestamps.
regards,
Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-10 10:37:08 CEST