From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13135 invoked by alias); 9 Dec 2001 02:05:57 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12898 invoked from network); 9 Dec 2001 02:04:40 -0000 Received: from unknown (HELO sj1-3-4-16.iserver.com) (192.220.127.209) by sources.redhat.com with SMTP; 9 Dec 2001 02:04:40 -0000 Received: (qmail 43435 invoked by uid 19025); 9 Dec 2001 02:04:39 -0000 Date: Sat, 08 Dec 2001 18:05:00 -0000 From: Jason Molenda To: Hilfinger@otisco.mckusick.com Cc: gdb@sources.redhat.com Subject: Re: More code code dropping Message-ID: <20011208180439.A42902@molenda.com> References: <20011129005901.A60085@molenda.com> <200112070641.WAA01521@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200112070641.WAA01521@localhost.localdomain>; from hilfingr@otisco.mckusick.com on Thu, Dec 06, 2001 at 10:41:36PM -0800 X-SW-Source: 2001-12/txt/msg00100.txt.bz2 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