I just had a battle with a build procedure -- quite possibly one that
isn't really done right -- that made me rethink the earlier discussion
about file timestamps.
The situation (I think) is that there's a directory that contains some
generated files as well as the files from which they are created.
Something like configure.in and configure, for example. And in our
regular build procedure we depend on the generated files; we don't go
all the way back to the beginning. Part of the reason may be that we
don't have all those tools installed.
With CVS, I believe the original file timestamps carry over. So the
generated files appear newer, in my working directory, than their
sources. That means that dependencies work correctly.
With Subversion, by default, the timestamps are checkout time. More
precisely, the time when a particular file was created by the
checkout. Depending on the order in which files come across from the
server, that may mean the generated file appears a few seconds older
than its source file. And that is what happened to us.
So the build procedure failed, because it tried to regenerate the
generated file and things weren't set up for that.
If we use the commit-time option, this problem would be avoided. That
package of files is probably an import, committed all at once, so the
entire set of files would have the same timestamp. That means the
generated file is "not newer" and things are ok.
The proposal of preserving the committer's last-modified times would
also work, of course.
Turning on commit-time would cover this case. But it will cause
problems if a plain ordinary source file is changed after my checkout
but before my last build. It would appear old, and it shouldn't.
How about this solution:
Checkout (and switch) use the commit time, or the original
modification time. But update uses the update time.
If that were an option I think it would be the best of both worlds.
It might seem messy, but it seems to have better properties for the
user than any of the existing choices.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 9 01:37:11 2006