On Fri, 2003-02-14 at 06:57, Wolf Josef wrote:
> What is the exact reason for this sleep? Has it something to do with
> make(1) or are there additional reasons beyond make?
When we create a working copy file, we record its timestamp in the
entries file. Later, when we want to check if a file has been modified,
we look at the file's stat() information and see if the timestamp has
changed. If it hasn't, we assume the file is unmodified; if it has, we
check the contents, which is a much slower operation.
However, most operating systems and filesystems only store the mod time
to the nearest second. So if we didn't have this sleep, an "svn update"
followed very quickly by an "echo foo >> foo.c" would not result in any
change to foo.c's timestamp, and we would not detect that it was
modified.
> > And I would say the time
> > of the last commit isn't the right answer; the right answer is a
> > timestamp property set on the file (which we don't current set). That
> > way you could a import a collection of files with this property set on
> > each file, and a checkout would have the same timestamps--a property
> > many build systems want to ensure.
>
> This seems somewhat odd to me. Let's assume:
>
> $ svn up -r HEAD
> $ make
> $ svn up -r PREV
> $ make
>
> In this example make will fail to rebuild if you change the timestamp
> to the older value. Therefore it seems the best not to fiddle with the
> timestamp and rely on the OS to do it right.
"Rely on the OS to do it right" is what we do now. But it interferes
with importing a lot of third-party software into version control
systems. For instance, most software which uses automake contains a
Makefile rule which rebuilds the configure script if it appears to be
out of date. (Sometimes that rule is conditional on configuring with
--enable-maintainer-mode, but that's up to the software package
maintainer, which means in many packages the rule is unconditional.)
That rule may require a specific version of autoconf to be installed on
the system, a requirement that isn't supposed to apply to
non-developers. When you import such a package into a version control
system and check it out again, the timestamps will be scrambled if you
"rely on the OS to do it right." In my work environment, we make copies
of the sources and run "find . ! -type l -exec touch -t `date
+%Y%m%d%H%M.%S`" over them before building, but that's an ugly solution.
Naturally, if you complain to software build system people they will
blame your version control system for not behaving like "tar", and if
you complain to version control people they will blame the build
systems.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 14 13:12:57 2003