automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: FAQ chapter for the manual (LONG)


From: Ronald Landheer-Cieslak
Subject: Re: RFC: FAQ chapter for the manual (LONG)
Date: Thu, 6 Feb 2003 18:55:55 +0100 (CET)

On Thu, 6 Feb 2003, Alexandre Duret-Lutz wrote:
> As English is obviously not my mother tongue, and because I know
> some people have strong opinions about some of the issues
> discussed, I'd appreciate any comments.
Don't beat yourself up too much - your english is fine :)

> Cheerio,
  ^^^^^^^
You sure you're not British? ;)

[snip]

> Background: CVS and timestamps
> ------------------------------
> 
>    CVS does not preserve timestamps.  The modification time of a
> CVS-controlled file is its checkout date.  Because CVS processes files
> in alphabetical order, `configure.in' will appear older than
> `configure' after a fresh checkout, even if `configure' was up-to-date
> when it was checked in.
> 
>    In other words, `make' relies on timestamps, CVS messes up
> timestamps, so these two tools do not work well together.

I beg to differ: use the -d option with import keeps the modification 
time, and The "commit" command retains the timestamp of the file, if the 
act of checking it in didn't change it (by expanding keywords).

AFAICT, neither autoconf nor automake nor libtool adds any CVS keyswords 
(like $Id$, for example) - but correct me if I'm wrong :)

> Living with CVS in Autoconfiscated projects
> -------------------------------------------
> 
>    There are basically two clans amongst maintainers: those who keep all
> distributed files under CVS, including generated files, and those who
> keep generated files _out_ of CVS.
> 
> All files in CVS
> ................
> 
>    * The CVS repository contains all distributed files so you know
>      exactly what is distributed, and you can checkout any prior
>      version entirely (except for timestamps).
                         ^^^^^^^^^^^^^^^^^^^^^
not true.

[snip]
>    * Although we focused on spurious rebuilds, the converse can also
>      happen.  CVS's timestamp handling can also let you think an
>      out-of-date file is up-to-date.
> 
>      For instance, suppose a developer has modified `Makefile.am' and
>      rebuilt `Makefile.in', and then decide to do a last-minute change
>      to `Makefile.am' right before checking in both files (without
>      rebuilding `Makefile.in' to account for the change).
.. and while having a CVS tag in the Makefile.am file (which is quite 
common)

>      This last change to `Makefile.am' make the copy of `Makefile.in'
>      out-of-date.  Since CVS processes files alphabetically, when
>      another developer update his or her tree, `Makefile.in' will
>      happen to be newer than `Makefile.am'.  This other developer will
>      not see `Makefile.in' is out-of-date.
.. the CVS tag will have been propagated to Makefile.in, which will make 
sure both files are touched.

I haven't read the rest yet (but I assume it's not about timestamping) but 
AFAIK the problem with generated files in CVS is not a problem of time 
stamps (file modification times) but rather of CVS keyword expansion.

In any case, CVS is a versioning tool, not a distribution tool. For me, 
that means that it makes sense not to have generated files in the CVS 
repository.

Just my two cents

rlc






reply via email to

[Prev in Thread] Current Thread [Next in Thread]