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 <e...@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 > _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
