[348] in Athena User Interface
An evil idea to deal with source rebuilds
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Aug 7 16:15:59 2000
Date: Mon, 7 Aug 2000 16:15:53 -0400
Message-Id: <200008072015.QAA07719@egyptian-gods.MIT.EDU>
From: Greg Hudson <ghudson@MIT.EDU>
To: source-developers@MIT.EDU, aui@MIT.EDU
The Athena source tree and the aui maintainers have had a lot of
difficulty with importing third-party packages which ship with
automatically generated files (which is most of them) and which have
Makefiles which might try to rebuild those files if they appear out of
date. There are various workarounds which can allow us to disable the
rebuilding of pre-built files, but the fundamental problem is that CVS
makes source files appear out of date with respect to each other when
they aren't; "cvs import" followed by "cvs checkout" does not preserve
timestamps. Even if we take the atttitude that a normal build should
never touch the shipped sources, it would be good to have a mechanism
to know if a pre-built source file is out of date with respect to what
it gets built from.
In the long run, an improved version control system like Subversion
(subversion.tigris.org) which provides metadata versioning can solve
our problem. But we don't live in the long run, so here is my
horrible kludgy idea for how to work around CVS's behavior:
The idea stems from the "cvs import -d" flag, which uses the imported
file's modification time as the time of the imported revision (and
thus the mod time for a checked out file). That option isn't
appropriate a priori, since it breaks a checkout by date (if I cvs
import a package and then cvs co -D yesterday, I shouldn't see the
files I just imported). But that problem goes away if we first run a
script or program which compressed the timestamps on a tree of files
so that they all have the same relative order but are all between the
current time and N seconds in the past, where N is the number of files
in the tree. Now no file would appear to be spuriously out of date
with respect to any other file in the tree, and checkouts by date
would not be appreciably harmed unless the number of files is huge.
It might be that preserving timestamp order in an entire tree is
overkill, and that we only need to preserve order within directories.
That would reduce the time skew relative to the current time required
to preserve ordering, but I'm tempted to preserve ordering of the
entire tree, just to make sure the dependency problem is killed dead.
Even though this idea is pretty evil, the problem it solves is pretty
large, so I'm leaning in favor of going with it. I'm thinking of
implementing it as a perl script which lives in the repository CVSROOT
directory, and then changing the instructions for importing
third-party packages to mandate that you run this script and use cvs
import -d. Yell if you think this is inappropriate.
An even more evil idea is to adjust the timestamps of sources we have
already imported in order to retroactively fix the problem for
existing packages. But I think that's hard enough to implement that
we'd probably want to just do it by hand or not do it at all.
