From: David Carlton <carlton@math.stanford.edu>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: [maint] Guidelines for experimental branches
Date: Mon, 03 Mar 2003 23:37:00 -0000 [thread overview]
Message-ID: <ro1smu4f2dl.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <3E63E3D3.6070401@redhat.com>
On Mon, 03 Mar 2003 18:22:59 -0500, Andrew Cagney <ac131313@redhat.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.
> +@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
next prev parent reply other threads:[~2003-03-03 23:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-03 23:23 Andrew Cagney
2003-03-03 23:37 ` David Carlton [this message]
2003-03-04 0:09 ` Andrew Cagney
2003-03-04 4:19 ` Eli Zaretskii
2003-03-04 11:04 ` Michal Ludvig
2003-03-05 1:31 ` Diego Novillo
2003-03-05 10:32 ` Michal Ludvig
2003-03-05 15:14 ` Diego Novillo
2003-03-05 17:06 ` Andrew Cagney
2003-03-04 2:08 Michael Elizabeth Chastain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ro1smu4f2dl.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=ac131313@redhat.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox