Re: More code code dropping

[Jason Molenda <jason-swarelist@molenda.com>]

On Thu, Dec 06, 2001 at 10:41:36PM -0800, Paul N. Hilfinger wrote:

> Not having
> done this before, however, I'd appreciate knowing the appropriate procedure
> for making such a deposit.

I thought my process was a reasonable one when I made the Apple
snapshot.  Our last merge to the FSF was Nov 2000, so the patch I
created showed the differences between our sources and the Nov 2000
FSF sources.  When I have some time, I plan to make another snapshot
of our sources against the current sources (Klee has brought our
internal gdb branch up to date with the FSF sources recently).  I
think trying to do both of these - send in your changes and update
your changes against the current gdb snapshots - will make the
process more difficult to complete.

When creating the diff, I used the obvious diff options; -Nwup if
I remember correctly.  I added -w because we had many meaningless
whitespace changes in our sources and I didn't want to bloat the
patch.

After doing this, I looked over my patch with diffstat to see the
distribution of changes and get a feel for whether the patch makes
sense.  I was doing my diff with cvs, and cvs was unhelpful when
the changes to a file were entirely whitespace - I'd end up with
an empty patch to that file (just the patch header, no actual
patches).  These don't cause any problems, but they make it look
like the patch is more widespread than it really is.  I removed
them by hand.

  (incidentally, if you are using cvs to do this, I'd try to use
   cvs 1.11 on the server and client - it records the directories
   in the diff filenames.  It makes patching infinitely easier.
   The cvs server on sourceware is still 1.10 for complicated
   reasons.)

Incidentally, I know you'll be diffing against an import in your
own tree or the gdb 5.0 tarball, but I was doing it against the
FSF cvs sources, so I found it very helpful to rsync over a copy
of the gdb CVS repository to my local system while I was doing all
these operations.  This also meant I could use cvs 1.11 on my local
system and get the pretty diffs that I wanted.  Details here:
	http://sourceware.cygnus.com/sourceware/rsync.html

When completed, I bzip2'ed the patch, and I included a .bz2 tarball
of the correctly patched sources.  In theory anyone should be able
to recreate that tarball given the patch file and the original
sources, but why not make it a bit easier for them.  That tarball
and patch are in
	ftp://sourceware.cygnus.com/pub/gdb/contrib

with a README file pointing to my mailing list announcement about
it and a short description of what these files are.  We might as
well give some tips to some poor sucker trying to understand what
these random files are years from now. :-)

I think the whole process took me five or six hours, but I had some
issues with cvs which added a fair amount of time.  A no-thinking-allowed
approach could finish this task in under an hour, I'm sure.

Hope that helps,

Jason