On Sun, 16 Oct 2005, Daniel Berlin wrote: > Note that this is a pretty straightforward conversion, but the whole > script is really overkill for the following reason: > > We can now identify the exact version of gcc t have simply by the > revision number and branch name. So maintaining all this stuff in a > DATESTAMP, etc, is severe overkill when you could simply use the result > of "svnversion .' and commit that to a file, or do it client side).
I think we want a meaningful version in the --version output regardless of how someone got GCC (including where what they have is not an SVN tree and so can't have svnversion run in it; e.g. obtained with svn export). If a hook can make every commit update (on whatever branch or branches are affected by that commit) a checked in file with the output of svnversion in, in addition to the files explicitly modified by that commit, that would suffice. Otherwise I think we want to keep a checked in datestamp file. I do think the LAST_UPDATED file created if someone uses gcc_update should be replaced with a file with information on the branch and revision number instead. Unlike the present situation where LAST_UPDATED can be misleading if a repository mirror is used (checkout sometime after the mirror is updated, in which time the master repository has had some more commits), information with branch and revision number would be accurate even with repository mirrors. > I will finish updating the gcc_release script today. Presumably, no longer tagging any snapshots, instead just reporting the revision number and branch name in the snapshot announcements? > The other contrib scripts have been updated by Ben Elliston, and were > posted to gcc-patches. And the other maintainer-scripts scripts (update_web_docs*)? -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
