From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8608 invoked by alias); 4 Mar 2003 00:09:24 -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 8601 invoked from network); 4 Mar 2003 00:09:23 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 4 Mar 2003 00:09:23 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BBA422A9C; Mon, 3 Mar 2003 19:09:21 -0500 (EST) Message-ID: <3E63EEB1.6010803@redhat.com> Date: Tue, 04 Mar 2003 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Carlton Cc: gdb@sources.redhat.com Subject: Re: [maint] Guidelines for experimental branches References: <3E63E3D3.6070401@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00067.txt.bz2 >> +@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?) You assume I know the answer :-) >> +@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. True, however ... >> + >> +@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? ... this shouldn't be a substitute for the CVS manual (What's missing is a reference to the CVS documentation). My motivation for mentioning the above commands was to draw peoples attention to the very efficient rtag :-) >> +@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. It's on the web :-) All doco is generated daily. > 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? Yes. A things-to-do-today item is get as many the web pages into texinfo. I figured that I'd put this stuff in texinfo from the start. To have the link working correctly though, someone (...) will need to look at makeinfo since that, unlike texi2html, gives each page a name ... thanks, Andrew