Inconsistance in snapshots repository

Inconsistance in snapshots repository

[Gabriel Dos Reis]

% ls egcs.cygnus.com:/pub/egcs/snapshots/

1.0.1-prerelease/     1997-10-16/           1998-02-14/
1.0.2-prerelease/     1997-10-23/           1998-02-21/
1997-08-14/           1997-10-31/           1998-03-02/
1997-08-21/           1997-11-05/           1998-03-08/
1997-08-25/           1997-11-14/           1998-03-15/
1997-08-28/           1997-11-22/           1998-03-21/
1997-09-01/           1997-11-27/           1998-03-28/
1997-09-04/           1997-12-01/           1998-04-06/
1997-09-07/           1997-12-07/           1998-04-11/
1997-09-10/           1997-12-15/           LATEST-IS-1998-04-06 <----
1997-09-17/           1997-12-25/           LATEST-IS-1998-04011 <----
1997-09-22/           1998-01-15/           README
1997-09-24/           1998-01-22/           core/
1997-09-29/           1998-01-29/           index.html
1997-10-08/           1998-02-05/           old/

One LATEST-IS-1998-04xxxxxx should be sufficient :-)

BTW, the mirror respository ftp.lip6.fr:/pub/egcs/snapshots/1998-04-11/
is incomplete.

Cheers,
-- Gaby

Re: Inconsistance in snapshots repository

[Jeffrey A Law]

snapshot dir problem: fixed, including the typo in the name.

mirror problem: out of my hands.  One can only hope it'll re-sync
itself.

jeff

Re: Inconsistance in snapshots repository

[Gerald Pfeifer]

On Tue, 14 Apr 1998, Gabriel Dos Reis wrote:
> 1997-09-10/           1997-12-15/           LATEST-IS-1998-04-06 <----
> 1997-09-17/           1997-12-25/           LATEST-IS-1998-04011 <----

On a related note, I realized that in the CVS repository gcc/version.c
still has "egcs-2.91.23 980404".

On another related note: What happended to the idea of bumping the date
more regularily, e.g., daily?

And on a final related note, I suggest to use 19980404 instead of 980404,
unless egcs won't be Y2000-compliant! <g>

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Inconsistance in snapshots repository

[Alexandre Oliva]

Gerald Pfeifer writes:

> And on a final related note, I suggest to use 19980404 instead of 980404,
> unless egcs won't be Y2000-compliant! <g>

BTW, would it be possible to have a ``moving tag'' called
`egcs_latest_snapshot', updated whenever a snapshot is released?

With this, I would be able to simply `cvs update' my CVS tree, instead 
of having to `cvs update -r egcs_ss_<snapshot>'.  This has got harder
over time, since snapshots are released with dates from 2-3 days ago,
and I was bitten by a mistyped date more than once already.  Jeff?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Inconsistance in snapshots repository

[Jeffrey A Law]

  In message < orpviju78e.fsf@zecarneiro.lsd.dcc.unicamp.br >you write:
  > Gerald Pfeifer writes:
  > 
  > > And on a final related note, I suggest to use 19980404 instead of 980404,
  > > unless egcs won't be Y2000-compliant! <g>
  > 
  > BTW, would it be possible to have a ``moving tag'' called
  > `egcs_latest_snapshot', updated whenever a snapshot is released?
This is an excellent idea.  The only trick is to coordinate it with
the actual "release" of a snapshot.

It would require another checkout and tag operation to occur when
the snapshot is actually released.  And thus has to be done outside
of the normal snapshot script (and therefore is more prone to user
error).

  > With this, I would be able to simply `cvs update' my CVS tree, instead 
  > of having to `cvs update -r egcs_ss_<snapshot>'.  This has got harder
  > over time, since snapshots are released with dates from 2-3 days ago,
  > and I was bitten by a mistyped date more than once already.  Jeff?
In general, I'd like to make the snapshots available immediately,
but I haven't had time to double check them for accuracy in a timely
manner lately.

The message probably won't go to the list for 24hrs since we want the
snapshots to propagate to the mirrors, but I'd really like to make
the snapshot available as soon as the script is finished.  This would
also allow the "latest snapshot tag" to be maintained by the snapshot
script itself.

jeff

Re: Inconsistance in snapshots repository

[Raja R Harinath]

Jeffrey A Law <law@cygnus.com> writes:

>   In message < orpviju78e.fsf@zecarneiro.lsd.dcc.unicamp.br >you write:
>   > Gerald Pfeifer writes:
>   > 
>   > > And on a final related note, I suggest to use 19980404 instead of 980404,
>   > > unless egcs won't be Y2000-compliant! <g>
>   > 
>   > BTW, would it be possible to have a ``moving tag'' called
>   > `egcs_latest_snapshot', updated whenever a snapshot is released?
> This is an excellent idea.  The only trick is to coordinate it with
> the actual "release" of a snapshot.
> 
> It would require another checkout and tag operation to occur when
> the snapshot is actually released.  And thus has to be done outside
> of the normal snapshot script (and therefore is more prone to user
> error).

Wouldn't

  cvs -d /path/to/repo rtag -r egcs_ss_YYYYMMDD -F egcs_latest_snapshot egcs

do the trick.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: Inconsistance in snapshots repository

[Jeffrey A Law]

  In message < d9pviiz5ol.fsf@sejong.cs.umn.edu >you write:
  > Wouldn't
  > 
  >   cvs -d /path/to/repo rtag -r egcs_ss_YYYYMMDD -F egcs_latest_snapshot egcs
I'm not sure.  The documentation on the exact behavior of -r with
tag/rtag was unclear when I looked at the documentation.

My (rather quick) reading of the docs led me to believe that
command would:

  Tag all the head revision for all files containing the tag
  egcs_ss_YYYYMMDD.

But it's possible I mis-understood -- this was one of the things 
I'd planned to experiment with.

jeff

Re: Inconsistance in snapshots repository

[Craig Burley]

>  > BTW, would it be possible to have a ``moving tag'' called
>  > `egcs_latest_snapshot', updated whenever a snapshot is released?
>This is an excellent idea.  The only trick is to coordinate it with
>the actual "release" of a snapshot.

I'm CVS-unaware, but, generally, is this really guaranteed to provide
a coherent snapshot to anyone, anytime, including if they try using
it while a snapshot is being produced (and the "moving tag" updated)?

That is, is whatever procedure people normally use to obtain a
snapshot via CVS guaranteed to obtain either all the files for
snapshot N *or* all the files for P, but never a mix, if, partway
through said obtaining, snapshot N is "replaced" as the "latest"
with snapshot P?

(E.g. I could think of this moving tag idea as perhaps a symbolic
link to a directory containing a snapshot in a non-CVS universe.
Whenver a new snapshot is made, after its directory is fully
populated and coherent, the symbolic link is simply updated.  That
works fine for simple uses like "cd .../symbolic-link; cp -a * ...",
because cd'ing to a symbolic link really cd's to the directory it
points to, at least in most cases; it's not just an updating of
some environment symbol.  But, in effect, it *might* be if the
target directory is mounted by NFS.  Further, if the procedure is
more complicated, e.g. "cp -a .../symbolic-link/file-a ...; cp
-a .../symbolic-link/file-b ...; cp -a .../symbolic-link/file-c ...",
then a change to the symbolic link *can* affect the procedure
midstream.)

If the answer to the above is not definitely "yes, it's always
guaranteed", then I think it's best to set up whatever means
is appropriate to *designate* a given snapshot as the "latest"
and encourage everyone to use procedures that obtain that
designation only *once* per snapshot-grab.  In essence, copy
that designation to a local temporary variable that is thus
guaranteed to not change while the snapshot is obtained (using
that same temporary variable to specify the stuff being obtained).

        tq vm, (burley)

Re: Inconsistance in snapshots repository

[Jeffrey A Law]

  In message < 199804162331.TAA25018@melange.gnu.org >you write:
  > I'm CVS-unaware, but, generally, is this really guaranteed to provide
  > a coherent snapshot to anyone, anytime, including if they try using
  > it while a snapshot is being produced (and the "moving tag" updated)?
Nope.  But what it does do for the CVS folks is allow them to 
upgrade to whatever the current snapshot happens to be without
knowing the exact name of the tag.  I think that was the idea
behind the suggestion.  The tag doesn't move until I make the
snapshot available.

And the window where things can get out of sync is relatively small;
directories are locked as the tag is added/moved.

[ I'm not a CVS expert - there may or may not be things in CVS to
  prevent the following "problems". ]

To get an out of sync tree you'd have to start after the tag process
and somehow get ahead of the tag process (might be able to happen if
for example you don't have some subdirs and can "leap frog" over
the tag process while the tag process walks through the subdirs.

Another possibility would be an update starting after tagging, then
both the update & tag block waiting on the same lock.  The updater
might be able to get the lock before the tagger and get an inconsistent
tree.

The opposite of those cases might be able to happen too.

In both situations another cvs update ought to fix any
inconsistencies.


I don't consider these serious prolems (if they exist at all), but
others may disagree.

jeff

Re: Inconsistance in snapshots repository

[Joe Buck]

In message < 199804162331.TAA25018@melange.gnu.org >you write:
>   > I'm CVS-unaware, but, generally, is this really guaranteed to provide
>   > a coherent snapshot to anyone, anytime, including if they try using
>   > it while a snapshot is being produced (and the "moving tag" updated)?
> Nope.  But what it does do for the CVS folks is allow them to 
> upgrade to whatever the current snapshot happens to be without
> knowing the exact name of the tag.

Ah, but it seems like a lot of work.  How about

finger latest-egcs-snapshot@cygnus.com

to find that out?  It certainly would be more robust.

Re: Inconsistance in snapshots repository

[Jeffrey A Law]

  In message < 199804171629.JAA04146@atrus.synopsys.com >you write:
  > In message < 199804162331.TAA25018@melange.gnu.org >you write:
  > >   > I'm CVS-unaware, but, generally, is this really guaranteed to provide
  > >   > a coherent snapshot to anyone, anytime, including if they try using
  > >   > it while a snapshot is being produced (and the "moving tag" updated)?
  > > Nope.  But what it does do for the CVS folks is allow them to 
  > > upgrade to whatever the current snapshot happens to be without
  > > knowing the exact name of the tag.
  > 
  > Ah, but it seems like a lot of work.  How about
  > 
  > finger latest-egcs-snapshot@cygnus.com
  > 
  > to find that out?  It certainly would be more robust.
Actually, it turns out the cvs command posted to this group will
do the right thing.

So, at the time I make the snapshot available I just issue the magic
CVS command, and in 2-5 minutes the "latest snapshot" tag is in
place.

Folks can then check out the tree using a sticky tag, later "cvs update"
operations will only change things if there's been a newer snapshot
made.

jeff

Re: Inconsistance in snapshots repository

[Alexandre Oliva]

Craig Burley <burley@gnu.org> writes:

>> > BTW, would it be possible to have a ``moving tag'' called
>> > `egcs_latest_snapshot', updated whenever a snapshot is released?
>> This is an excellent idea.  The only trick is to coordinate it with
>> the actual "release" of a snapshot.

> I'm CVS-unaware, but, generally, is this really guaranteed to provide
> a coherent snapshot to anyone, anytime, including if they try using
> it while a snapshot is being produced (and the "moving tag" updated)?

Nope.  If you checkout or update the moving tag while it is being
moved, you may get some files from the previous snapshot and some from 
the new one.

However, since snapshots are produced weekly, and we can count on
having this tag moved just before the announcement, there's high
probability that, if you update your tree just after getting an
announcement, it will be a coherent one.

Furthermore, if you fear you may have got an inconsistent snapshot,
just run `cvs update' again; if you get any changes, wait some time
for the moving tag to get stable or specify a fixed tag.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Inconsistance in snapshots repository

[Craig Burley]

>However, since snapshots are produced weekly, and we can count on
>having this tag moved just before the announcement, there's high
>probability that, if you update your tree just after getting an
>announcement, it will be a coherent one.
>
>Furthermore, if you fear you may have got an inconsistent snapshot,
>just run `cvs update' again; if you get any changes, wait some time
>for the moving tag to get stable or specify a fixed tag.

Good enough for me, especially if these reminders accompany any
document/email (automated or otherwise) that tell people about
the tag!

        tq vm, (burley)

Re: Inconsistance in snapshots repository

[Jeffrey A Law]

  In message < 199804170133.VAA25400@melange.gnu.org >you write:
  > >Furthermore, if you fear you may have got an inconsistent snapshot,
  > >just run `cvs update' again; if you get any changes, wait some time
  > >for the moving tag to get stable or specify a fixed tag.
  > 
  > Good enough for me, especially if these reminders accompany any
  > document/email (automated or otherwise) that tell people about
  > the tag!
Also good ideas.  Look for them in the next snapshot :-0

jeff

Re: Inconsistance in snapshots repository

[Jeffrey A Law]

  In message < Pine.GSO.3.96.980415001559.3746A-100000@alcyone.dbai.tuwien.ac.at
>you write:
  > On Tue, 14 Apr 1998, Gabriel Dos Reis wrote:
  > > 1997-09-10/           1997-12-15/           LATEST-IS-1998-04-06 <----
  > > 1997-09-17/           1997-12-25/           LATEST-IS-1998-04011 <----
  > 
  > On a related note, I realized that in the CVS repository gcc/version.c
  > still has "egcs-2.91.23 980404".
I'll look into it, probably a consequence of running the snapshot
script a few dozen times and tweaking it in the process.


  > On another related note: What happended to the idea of bumping the date
  > more regularily, e.g., daily?
No time.  Like most things a contribution of code would greatly
speed up the process.


  > And on a final related note, I suggest to use 19980404 instead of 980404,
  > unless egcs won't be Y2000-compliant! <g>
Probably a good idea, even those it's just a version string and
means nothing to the compiler itself.

jeff

Re: Inconsistance in snapshots repository

[Gerald Pfeifer]

On Tue, 14 Apr 1998, Jeffrey A Law wrote:
>> On another related note: What happended to the idea of bumping the date
>> more regularily, e.g., daily?
> No time.  Like most things a contribution of code would greatly
> speed up the process.

I'm not sure whether the following is what you have asked for, but...
Here we go:

-------- cut here --------
#!/bin/sh

cvs update version.c 

CURR_DATE=`date +"%Y%m%d"`
OLD_VERSION=`cat version.c`

sed -e "s/\(.*egcs-[^ ]*\) [^ ]*/\1 ${CURR_DATE}/" >version.c <<HERE
$OLD_VERSION
HERE

cvs commit -m "Daily bump." version.c 
-------- cut here --------

Is that useable for you?


>> And on a final related note, I suggest to use 19980404 instead of 980404,
>> unless egcs won't be Y2000-compliant! <g>
> Probably a good idea [...]

Indeed I noticed that the latest snapshot now carries a 4-digit year, so
none can complain about my script introducing this... ;-)

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Inconsistance in snapshots repository

[Jeffrey A Law]

  In message <Pine.GSO.3.96.980423203837.6934Q-100000@alcyone.dbai.tuwien.ac.at
>you write:
  > On Tue, 14 Apr 1998, Jeffrey A Law wrote:
  > >> On another related note: What happended to the idea of bumping the date
  > >> more regularily, e.g., daily?
  > > No time.  Like most things a contribution of code would greatly
  > > speed up the process.
  > 
  > I'm not sure whether the following is what you have asked for, but...
  > Here we go:
Close.  It needed a few minor tweaks to make it a little more
"crontab" safe/aware.  We'll know if it works in about 45 minutes :-)

Note now that the date string is updated daily the date string will
no longer be updated by the snapshot script.  The snapshot script
will only update the version #.

jeff