From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20596 invoked by alias); 3 Mar 2003 23:37:35 -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 20578 invoked from network); 3 Mar 2003 23:37:34 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 3 Mar 2003 23:37:34 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h23NbQ314221; Mon, 3 Mar 2003 15:37:26 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: [maint] Guidelines for experimental branches References: <3E63E3D3.6070401@redhat.com> From: David Carlton Date: Mon, 03 Mar 2003 23:37:00 -0000 In-Reply-To: <3E63E3D3.6070401@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg00065.txt.bz2 On Mon, 03 Mar 2003 18:22:59 -0500, Andrew Cagney said: > Comments, throughts, overspecified? Great! I was planning to write something up containing the mechanics of branch creation, but you've beaten me to it. > +@item a branch shall contain the entire @value{GDBN} module > +The @value{GDBN} module @code{gdb} or @code{gdb+dejagnu} should be > +specified when creating a branch (branches of individual files should be > +avoided). Maybe also mention insight, insight+dejagnu? (And, for that matter, to give some guidance as to when "+dejagnu" is appropriate?) > +@smallexample > +cvs rtag @var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint gdb+dejagnu > +cvs rtag -b -r @var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint \ > + @var{owner}_@var{name}-@var{YYYYMMDD}-branch gdb+dejagnu > +@end smallexample It might also be nice to give an example of how to actually check out the branch here. > + > +@item @var{owner}_@var{name}-@var{yyyymmdd}-mergepoint > +The tagged point, on the mainline, that was used when merging the branch > +on @var{yyyymmdd}. To merge in all changes since the branch was cut, > +use a command sequence like: > +@smallexample > +cvs rtag @var{owner}_@var{name}-@var{yyyymmdd}-mergepoint gdb+dejagnu > +cvs update \ > + -j@var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint > + -j@var{owner}_@var{name}-@var{yyyymmdd}-mergepoint > +@end smallexample I would consider adding "-kk" to the cvs update flags: it doesn't matter for core GDB, but I _think_ it will help for, say, TCL. Also, might it be useful to give some guidance about how to detect collisions (redirecting stdout+stderr to a file, etc.), or is that not necessary? > +@section Active branches > + > +@subheading cagney_@var{offbyone}-20030303-branch > +Test fixes to a problem with the wrong frame ID unwind method being > +called (with the wrong frame cache). My first reaction is "shouldn't this be on a web page somewhere?". On the other hand, it's not like I've ever edited the GDB web pages; it's easier for branch creaters to edit gdbint.texinfo. But I still think this sort of info should be accessible via a web page; maybe put a link on a GDB web page (current cvs?) to a web copy of this section of gdbint.texinfo? David Carlton carlton@math.stanford.edu