Subject: cvs id in version info

From: Dominik Vogt <[email-masked]>
Date: Sat, 12 Oct 2002 09:37:38 +0200

Can you think of a way to include the check out date in the version
info and bug reports if someone pulled fvwm from CVS?  As far as I
can see, CVS only spits out the check in date, not the check out
date.  Let's disregard the case that someone checks out only a sub
directory and assume either "cvs update" or "cvs checkout" is run
in the top level directory.

Of course, a new CVS check out should not force you to recompile
or reconfigure everything.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 12 Oct 2002 15:28:30 +0000

> or reconfigure everything.

This is the problem, not to rerun anything, but still to update the
version info string everywhere! :) Actually I think it is acceptable if
all files that use version info are regenerated after each non-zero
update, because we want this.

Theoretically, I see several possible solutions, all not really working.
First is to run "date +%Y-%m-%d >.cvsdate" on the server on every commit
and mark .cvsdate as non ignored, but still always-overridden-
without-conflicts file. Unfortunately, cvs does not have such concept.

Second is to use some $Date$ variables that are substituted by cvs and
then are extracted by our script, but  the problem, it should be the date
of the cvs repository, not of some certain file.

The best I can suggest is to scan CVS/Entries */CVS/Entries for ChangeLog
dates, but still there is an autoconf problem, when exactly to rerun this
code (on every make, when date of .cvsstamp is changed?).

I ran out of ideas, maybe someone else has something workable.

Regards,
Mikhael.