public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gerald Pfeifer <gerald@pfeifer.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: Gary Funck <gary@intrepid.com>, Gcc Patches <gcc-patches@gcc.gnu.org>
Subject: Re: gcc_release script, snapshots, and LAST_UPDATED version
Date: Fri, 28 Jan 2011 20:01:00 -0000	[thread overview]
Message-ID: <alpine.LNX.2.00.1101282029490.7158@gerinyyl.fvgr> (raw)
In-Reply-To: <Pine.LNX.4.64.1012201641530.6154@digraph.polyomino.org.uk>

On Mon, 20 Dec 2010, Joseph S. Myers wrote:
>>>  It's LAST_UPDATED, not LAST_CHANGED.  This is significant; the 
>>> revision number is indeed the revision at which the source tree was 
>>> last updated, not the revision at which the branch was last changed.
>> OK.  How is LAST_UPDATED more useful than LAST_CHANGED?  I would have
>> thought that it would be useful to know the last version on the branch
>> that is being snap-shotted.
> I think you should be doing your own interrogation of SVN information in 
> your snapshot script.  This file is for convenient identification of 
> checkouts for the use of scripts such as contrib/test_summary; the 
> information it contains is already formally redundant (both revision and 
> date, in different time zones).

I'm afraid you lost me here.  Given the example Gary used

   svn info -r167957 file:///svn/gcc/branches/gcc-4_5-branch
   Path: gcc-4_5-branch
   URL: file:///svn/gcc/branches/gcc-4_5-branch
   Repository Root: file:///svn/gcc
   Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
   Revision: 167957
   Node Kind: directory
   Last Changed Author: rguenth
   Last Changed Rev: 167948
   Last Changed Date: 2010-12-16 06:34:03 -0800 (Thu, 16 Dec 2010)

why do we want to use Revision: and not Last Changed Rev: to describe
the branch and accordingly make the following change to gcc_snapshot?

   -  SVNREV=`${SVN} info "${SVNROOT}/${SVNBRANCH}"|awk '/Revision:/ {print$2}'`
   +  SVNREV=`${SVN} info "${SVNROOT}/${SVNBRANCH}"|awk '/^Last Changed Rev:/ {print $4}'`

> It is not meant to contain everything that could possibly be of use in 
> describing a checkout, and certainly not everything relevant for making 
> a snapshot decision (for normal GCC snapshots, you might want to skip 
> them if only the DATESTAMP file - checked in - had been updated since 
> the last snapshot).

Isn't that backwards?  Should we not simply avoid updating DATESTAMP
if there have not been any changes since it's last update?

I'd love to improve this, just right now I'm simply a bit confused,
so any help, clarity or patches would be great.

Gerald

  reply	other threads:[~2011-01-28 19:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-20 11:08 Gary Funck
2010-12-20 15:07 ` Joseph S. Myers
2010-12-20 17:36   ` Gary Funck
2010-12-20 17:52     ` Joseph S. Myers
2011-01-28 20:01       ` Gerald Pfeifer [this message]
2011-01-28 20:42         ` Joseph S. Myers
2011-01-28 23:55           ` Gerald Pfeifer
2011-01-29 17:09         ` Gary Funck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.00.1101282029490.7158@gerinyyl.fvgr \
    --to=gerald@pfeifer.com \
    --cc=gary@intrepid.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).