[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: RFC: timestamps/sleep

From: Wolf Josef <josef.wolf_at_siemens.com>
Date: 2003-02-14 14:35:19 CET

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

This is an archived mail posted to the Subversion Dev mailing list.