[plt-dev] "Welcome to a new PLT day."

I've often thought it Would be better to use the svn (now git)
metainformation than the date. It seems more precise.

Robby

On Tuesday, May 4, 2010, Eli Barzilay <eli at barzilay.org> wrote:
> This daily commit has always bugged me, and this would be a good time
> to re-thing it.  I think that this is a good way to get rid of it:
>
> * Keep collects/repos-time-stamp, but make it look for the current
>   version as some the date and the sha1, and use that.  (It will look
>   for it in the root, straight from the git files.)
>
> * If it can't find that, it will use its own source's time stamp.
>
> * The nightly build will delete this whole thing and hard-wire the
>   information in.
>
> * Releases don't have the collection, as usual.
>
> The result of this cover almost all cases -- using a binary nightly
> build has the information, using a source from the nightly builds
> works too, and building from a repository works.
>
> The only case where this will not work (when it needs to resort to its
> own time stamp) is when someone grabs the source tree directly from
> git -- but not through a clone.  For example, both the gitweb
> interface (at http://git.racket-lang.org/plt/) and the github mirror
> allow you to download a tgz or zip with the sources.  The timestamp
> seems reliable in this case -- the archives that you get this way have
> the timestamp of the last commit.
>
> Can anyone think of any reason why this won't work, and/or any other
> reason to keep the nightly commit?
>
> (Note that when there are version changes it will still do a commit,
> as it always did, to keep the various files with versions (like the
> windows RC files) in sync.)
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-dev
>