Re: [maint] Guidelines for experimental branches

[Andrew Cagney <ac131313@redhat.com>]

>> +@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