Re: 980328 snapshot diff problem

Re: 980328 snapshot diff problem

[Jeffrey A Law]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

  In message <3524AB4D.803E7301@inka.de>you write:
  > > Hmmm, something must have gone wrong on your end to get these rejects --
  > > the snapshot process actually applies the diffs to the previous
  > > snapshot, then compares the result to the new snapshot and tells
  > > me if there are any differences.  That process did not trigger any
  > > differences for 0321-0328.
  > Well,I can easily reproduce that problem by doing the following
  > procedure :
[ ... ]
unpack 980205 via components,
then update via the full .diff files to upgrade to 980328
  > applying ../egcs-980321-980328.diff.gz
  > 1 out of 68 hunks FAILED -- saving rejects to .brik.rej
  > 1 out of 16 hunks FAILED -- saving rejects to texinfo/util/texi2dvi.rej
  > 
  > I don´t see what´s going wrong here. 
Somewhere, somehow, those two files got out of sync.    Possibly
others too, the trick is finding out when/how.

I used the same procedure as you and everything was fine up to and
including the 980321 snapshot -- verifying both via the .brik files
and by comparing to the full distribution (note your patch line is
slightly wrong -- it doesn't have the option to remove files which
are empty after patching, but that's a trivial nit).

The .brik reject occurs due to a bogus line "texinfo/util/j" -- 
it's in the diff, but not in the 0321 .brik file.

"texinfo/util/j" was a copy of texi2dvi (note that for later) that
was scrogged by the import of texinfo-3.??.  I forgot to delete it
after fixing texi2dvi in the repository.  

Note that since it was a copy of texi2dvi, it had all the tags for
the previous snapshots in it (including 980321 in particular).

The snapshot process actually rebuilds the previous snapshot so that
it can produce diffs between two snapshots.  Since this bogus file
had the tag for 980321 it got included in the new copy of 980321,
even though it wasn't in the real 980321.  This led to the bogus
line in the .brik file.

I don't immediately see what's wrong with the texi2dvi diff, but
I'm not too concerned about it since it is likely the case that the
CVS bug caused a minor difference between 980321 on the ftp dir
and the one it rebuilt as part of the 980328 snapshot process.

I'm more concerned that the snapshot process didn't note these
errors -- I'll be looking into that shortly :-)

I'll put copies of a copy of the .brik and texi2dvi in the next
snapshot so that folks can re-sync.

jeff