gcc_release script, snapshots, and LAST_UPDATED version

gcc_release script, snapshots, and LAST_UPDATED version

[Gary Funck]

I've been reviewing the maintainer-scripts/gcc_release shell script
for use in making gupc snapshots, and noticed that it may be using the
wrong svn revision number when updating the LAST_CHANGED file.

Here's the code:

   SVNREV=`${SVN} info "${SVNROOT}/${SVNBRANCH}"|awk '/Revision:/ {print $2}'`
   [...]
   echo "Obtained from SVN: ${SVNBRANCH} revision ${SVNREV}" > LAST_UPDATED

If we take a recent 4.5 snapshot as an example, we see the following:

$ cat gcc-core-4.5-20101216/LAST_UPDATED
Obtained from SVN: branches/gcc-4_5-branch revision 167957

If we obtain the info on that branch revision, we see
the following:

   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)

Trying to query that rev. on the 4.5 branch turns up nothing:
   $ svn log -r167957 file:///svn/gcc/branches/gcc-4_5-branch | head -20
But, as expected, querying the last changed rev. works just fine.
   $ svn log -r167948 file:///svn/gcc/branches/gcc-4_5-branch | head -20

Based on the discussion above, I think that the following change
would generate the correct version number in LAST_UPDATED:

   Index: maintainer-scripts/gcc_release
   ===================================================================
   --- maintainer-scripts/gcc_release      (revision 168012)
   +++ maintainer-scripts/gcc_release      (working copy)
   @@ -167,7 +167,7 @@ EOF
	  error "Could not tag sources"
	SVNBRANCH=${TAG}
      fi
   -  SVNREV=`${SVN} info "${SVNROOT}/${SVNBRANCH}"|awk '/Revision:/ {print $2}'`
   +  SVNREV=`${SVN} info "${SVNROOT}/${SVNBRANCH}"|awk '/^Last Changed Rev:/ {print $4}'`
    
      # Export the current sources.
      inform "Retrieving sources (svn export -r ${SVNREV} ${SVNROOT}/${SVNBRANCH})"

Re: gcc_release script, snapshots, and LAST_UPDATED version

[Joseph S. Myers]

On Sun, 19 Dec 2010, Gary Funck wrote:

> I've been reviewing the maintainer-scripts/gcc_release shell script
> for use in making gupc snapshots, and noticed that it may be using the
> wrong svn revision number when updating the LAST_CHANGED file.

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc_release script, snapshots, and LAST_UPDATED version

[Gary Funck]

On 12/20/10 11:54:51, 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.

What I wanted to do is to avoid creating a new snapshot (which are being
made daily) if there were no changes to the branch since the last snapshot.
Clearly, the script that makes this decision can't use LAST_UPDATED directly.
However, since "LAST_CHANGED" can be derived from LAST_UPDATED,
I can see where it is more general.

Re: gcc_release script, snapshots, and LAST_UPDATED version

[Joseph S. Myers]

On Mon, 20 Dec 2010, Gary Funck wrote:

> On 12/20/10 11:54:51, 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).  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).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc_release script, snapshots, and LAST_UPDATED version

[Gerald Pfeifer]

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

Re: gcc_release script, snapshots, and LAST_UPDATED version

[Joseph S. Myers]

On Fri, 28 Jan 2011, Gerald Pfeifer wrote:

> 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?

I have nothing to add here.  As far as I am concerned this is a bikeshed 
discussion; these things work and there is no use in changing them.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc_release script, snapshots, and LAST_UPDATED version

[Gerald Pfeifer]

On Fri, 28 Jan 2011, Joseph S. Myers wrote:
>> 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?
> I have nothing to add here.  As far as I am concerned this is a bikeshed 
> discussion; these things work and there is no use in changing them.

Note that I am not trying to argue either way, just understand the thing!

In any case, my concern and question really is the following:  How can
we best avoid creating a snapshot that is not worth it since it does
not have any relevant changes (just LAST_UPDATED).  I thought not
touching LAST_UPDATED in the absence of other changes was a way to
go, but there may be better ones.

Again, I am with you on not wanting to bikeshed; I just would like to
avoid useless ("empty") snapshots and am looking for help on how to
best, or easiest, implement that.

Gerald

Re: gcc_release script, snapshots, and LAST_UPDATED version

[Gary Funck]

On 01/28/11 20:32:58, Gerald Pfeifer wrote:
> 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}'`

Given: The change is known, and simple, and that the resulting
revision number is likely closer to what most users will agree is a better
indication of the "last update".  What is the impact on other users
and scripts that use the LAST_UPDATED version in its current form?

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

The auto-update of DATESTAMP without regard to whether any
changes have been made has always seemed problematic to me.
Perhaps if the "last changed" revision was queried by the script
that updates DATESTAMP, then needless DATESTAMP updates
can be avoided?  Alternatively, a trial export can be performed
and the old/new source trees can be compared, and DATESTAMP
only updated if source level diferences are indicated.  That
approach would miss metadata-only updates however.  Therefore,
the version check is likely superior?

As far as "bike shed" arguments go, my understanding is that
the key points are the tendency of a committee to (1) argue
at length over trivial/easy issues and to avoid lengthy
discussions of major/dificult issues, and (2) spending
time worrying about the color and composition of the
roof of the bike shed, rather than asking whether the
bike shed is needed.  I can see elements of point (1),
but not necessarily point (2).  This thread started from
the need to produce snapshots only when they actually
differ from their predecessor.  IMO, that is a useful
and worthwhile goal.  The alternatives push the work
of comparing snapshots out to the user, which seems
unnecessary (and error prone).

- Gary