On Tue, Feb 1, 2011 at 5:31 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > 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. >
I can't find it right now, but I read something recently about using hooks to put revision numbers inside source controlled files.
