Greg Hudson wrote:
> 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.
Ah, I see.
> "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.
But isn't configure _derived_ data which can be recreated at any time?
Why do you put such data under version control? IMHO only _real_ source
data (which can not be reconstructed automatically) belongs into a
version control system. If you don't put the configure script under
version control, you won't have a problem here. But I think I have
missed your point very badly ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 14 14:36:12 2003