On Mon, Jan 31, 2011 at 6:56 PM, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Mon, 31 Jan 2011, NightStrike wrote: > >> On Mon, Jan 31, 2011 at 7:51 AM, Richard Guenther >> <richard.guent...@gmail.com> wrote: >> > On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song >> > <dongsheng.s...@gmail.com> wrote: >> >> It's very simple (only for trunk, although it maybe more useful for >> >> branches): >> > >> > Or simply put Last-Changed-Date into DATESTAMP, not the >> > current date. >> >> This has other benefits as well, since it means that the date in the >> gcc version string becomes the date of the last actual revision, >> instead of the date that the datestamp change is committed. > > Not in the case where you have no datestamp changes for a month, say, then > some other change is committed, but a new datestamp change hasn't yet been > committed after that other change; then you have, for a limited period, a > compiler with a datestamp value long before the last commit. (That's the > main case I can think of for not making snapshots if only DATESTAMP has > changed, rather than the simpler approach of omitting some DATESTAMP > updates and not making snapshots if nothing at all has changed.)
The DATESTAMP change could also be in a post-commit hook (doing nothing if the date didn't change, of course). No idea whether this is technically possible of course. Richard.
