Re: Snapshot, diffs and crap

Re: Snapshot, diffs and crap

[Joseph H. Buehler]

mrs@wrs.com (Mike Stump) writes:

> > Date: Tue, 27 Jan 1998 15:31:00 +0100
> > From: Marc ESPIE <Marc.Espie@liafa.jussieu.fr>
> > To: egcs@cygnus.com
> 
> > Right now, `playing' with egcs without a fast internet link is a
> > nightmare, as you mostly have to get one full archive every snapshot
> > to get something reliable...
> 
> I did this for years using cvs on a 9600 link and then a 28.8 link.
> It is not a nightmare as you suggest.  Bottom line, use cvs with -z9.
> It works, it reliable and is nearly as fast as it can be.  Now, if you
> packet loss is >8%, your going to lose no matter what you try (except
> for a mirrow site that is closer).

Cvs is great for what I am doing: it has been taking maybe 5 or 10
minutes to sync my copy of the egcs source with cygnus.com if I do it
every couple days.  This sure beats downloading .tar.gz files or
messing with diffs as far as I am concerned.

You do sometimes have to have some extra tools, though, since file
timestamps are not maintained in the cvs tree, and this can cause some
extra things to need to be regenerated that you normally don't have to
worry about in the .tar.gz files.

Joe Buehler

Re: Snapshot, diffs and crap

[Marc Espie]

Okay, after getting the whole recent snapshot, it turns out that
only the .brik file was wrong. Turns out that my compilation failed
because I need a true `make bootstrap' this time. I didn't try on 
this machine (Amiga3000-openbsd) before, and I can't get away with
a simple `make' for the C++ library, even though a three stage build
will take *forever* (around 24 hours, I guess).

Sorry for the outburst. I actually appreciate quite a lot all the work
that has been going on in egcs.

There is another small difference between snapshot 980122 and
980115 + diffs: some bytecode files still exist in 980122, even though
they're actually empty.

I obviously have missed the message concerning the `wrong' .brik file.

As far as CVS comments go, I must point out that some of us use
configurations that make ftp the only viable way to procure snapshots.
I can retrieve files on a linux box that is directly connected to the net at 
the university, but I don't have enough room on that box to install a cvs
tree and let cvs run. Moreover, there is a local mirror (ftp.lip6.fr) which
is much faster than egcs can ever hope to be. 
When I get large archives, I connect my syquest easy-flyer to the linux
box and download the archives to the flyer directly. For small files, such
as snapshot diffs, I can forego the hastle and just pop a floopy-disk in.

Connecting the amiga at home is not that easy, and more to the point, it's
expensive. France still hasn't woken up to the world of modern 
telecommunications, so that downloading anything but the simplest mail takes
time and costs me money.

Bottom-line, snapshot + diffs is important for me. I'd like it to be
very reliable.

Related to the .brik problem, I don't quite understand how such a problem
could sneak in... I would have thought snapshot-building were designed to
enforce consistency. That is: build a new snapshot archive.
Unarchive old and new snapshot. Compute corresponding diff file.
Apply diff to old snapshot. Compare against new snapshot. Complain if there
is any discrepancy.
I don't see how the .brik file could get through the cracks.
For that matter, I noticed the empty byte-code files through diff myself.
They should have been apparent, wouldn't they.

As another related point, from what I've read, it seems that the current
CVS installation uses patch 2.1.

An upgrade to a more recent version of patch is vital.   This version does
not work with patches at the end of file. Under some circumstances, if you 
add something at the end of the file, build up the diff. then modify the 
original file elsewhere, so that the line count will change, patch will 
incorrectly apply the patch right smack where the end of the file used to be, 
without even complaining about wrong context.
I've been bitten by this one at least once.

Re: Snapshot, diffs and crap

[Jeffrey A Law]

  In message < 199801281706.SAA05624@quatramaran.ens.fr >you write:
  > Related to the .brik problem, I don't quite understand how such a problem
  > could sneak in... 
The way we created the .brik file was to list all the args on the
command line.

The old box which had the cvs repository and where we made snapshots
from allowed a much larger arg block than the new box.

In an attempt to fix it when moving snapshots to the new machine I
botched the script.


  > I would have thought snapshot-building were designed to
  > enforce consistency. That is: build a new snapshot archive.
  > Unarchive old and new snapshot. Compute corresponding diff file.
You're fine to here.

  > Apply diff to old snapshot. Compare against new snapshot. Complain if there
  > is any discrepancy.
We don't do this.  As the snapshot process becomes more automated this
might make sense.

  > For that matter, I noticed the empty byte-code files through diff myself.
  > They should have been apparent, wouldn't they.
You missed an arg to patch.  Whatever one that says to delete files
made empty by the patch process.

jeff

Re: Snapshot, diffs

[chip]

According to Jeffrey A Law:
>   > Apply diff to old snapshot. Compare against new snapshot. Complain if
>   > there is any discrepancy.
> We don't do this.  As the snapshot process becomes more automated this
> might make sense.

Jeff, when I did Perl snapshots, I relied on this step and it caught
one or two problems.  Please do it, even if you have to do it by hand.

Don't forget to compare important permissions (the executable bits,
for instance).
-- 
Chip Salzenberg               - a.k.a. -                <chip@pobox.com>
             "It's the lemon zester of death!!"   // MST3K

Re: Snapshot, diffs and crap

[Ian Lance Taylor]

   From: espie@quatramaran.ens.fr (Marc Espie)
   Date: Wed, 28 Jan 1998 18:06:27 +0100

   As another related point, from what I've read, it seems that the current
   CVS installation uses patch 2.1.

   An upgrade to a more recent version of patch is vital.   This version does
   not work with patches at the end of file. Under some circumstances, if you 
   add something at the end of the file, build up the diff. then modify the 
   original file elsewhere, so that the line count will change, patch will 
   incorrectly apply the patch right smack where the end of the file used to be, 
   without even complaining about wrong context.
   I've been bitten by this one at least once.

As I've mentioned before, if you get a version of CVS later than
1.9.10 from download.cyclic.com, CVS will not use patch at all, in
which case it does not matter which version you have.

I encourage everybody to get a up to date CVS, since not only does it
not require patch, it sends less data for each change to a file (it
sends diff -n output rather than diff -c output).

Ian

Re: Snapshot, diffs

[Jeffrey A Law]

  In message <199801290158.UAA06992@cyprus.atlantic.net>you write:
  > According to Jeffrey A Law:
  > >   > Apply diff to old snapshot. Compare against new snapshot. Complain if
  > >   > there is any discrepancy.
  > > We don't do this.  As the snapshot process becomes more automated this
  > > might make sense.
  > 
  > Jeff, when I did Perl snapshots, I relied on this step and it caught
  > one or two problems.  Please do it, even if you have to do it by hand.
Done for the main snapshot, not for all the little ones.

  > Don't forget to compare important permissions (the executable bits,
  > for instance).
Good point.

jeff