On Fri, Feb 14, 2003 at 02:35:19PM +0100, Wolf Josef wrote:
> Greg Hudson wrote:
> > "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.
In general yes, but you might have a vendor branch into which you're
importing somebody else's distribution, and in that case you need to
include the configure that they built. (I have several instances of this
among the Debian source packages in my repository.)
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
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:43:33 2003