This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] Guidelines for experimental branches
- From: David Carlton <carlton at math dot stanford dot edu>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: 03 Mar 2003 15:37:26 -0800
- Subject: Re: [maint] Guidelines for experimental branches
- References: <3E63E3D3.6070401@redhat.com>
On Mon, 03 Mar 2003 18:22:59 -0500, Andrew Cagney <ac131313 at redhat dot com> 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.
> + at 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?)
> + at smallexample
> +cvs rtag @var{owner}_ at var{name}-@var{YYYYMMDD}-branchpoint gdb+dejagnu
> +cvs rtag -b -r @var{owner}_ at var{name}-@var{YYYYMMDD}-branchpoint \
> + @var{owner}_ at var{name}-@var{YYYYMMDD}-branch gdb+dejagnu
> + at end smallexample
It might also be nice to give an example of how to actually check out
the branch here.
> +
> + at item @var{owner}_ at 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:
> + at smallexample
> +cvs rtag @var{owner}_ at var{name}-@var{yyyymmdd}-mergepoint gdb+dejagnu
> +cvs update \
> + -j at var{owner}_@var{name}- at var{YYYYMMDD}-branchpoint
> + -j at var{owner}_@var{name}- at var{yyyymmdd}-mergepoint
> + at 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?
> + at section Active branches
> +
> + at subheading cagney_ at 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 at math dot stanford dot edu