Re: New branch [was Re: RFC: MI output during program execution]

Re: New branch [was Re: RFC: MI output during program execution]

[Nick Roberts]

[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 1110 bytes --]

                                      ref no: 6.4.50.20060512-nickrob-async

Daniel Jacobowitz writes:
> On Fri, May 12, 2006 at 08:36:44PM +1200, Nick Roberts wrote:
 > > Actually thats quite a lot of data and probably not of general interest.
 > > Shall I just post the ChangeLog?
 > 
 > I suppose; I can always grab the branch and diff it myself.

I attach a compressed diff as its not as big as I had thought it would be.

 ...
 > > I can't get my head round mergepoints (what happens if someone elso commit
 > > after your tag but before your commit?) but I'll worry about that later.
 > 
 > The trick is that you do everything relative to the tags, including
 > merges and other tags - nothing relative to HEAD.
 > 
 >   - Create new tag
 >   - Merge changes from last tag to new tag to branch.

Perhaps I'm confusing things a bit.  Maybe mergepoints are just for merging
HEAD to branch.  Is any tagging needed when the branch gets merged to HEAD?
(possibly a bit hypothetical as I realise I may never get that far).


-- 
Nick                                           http://www.inet.net.nz/~nickrob



[-- Attachment #2: Changes for 6.4.50.20060512-nickrob-async --]
[-- Type: application/octet-stream, Size: 36487 bytes --]

Re: New branch [was Re: RFC: MI output during program execution]

[Daniel Jacobowitz]

On Sun, May 14, 2006 at 01:23:40PM +1200, Nick Roberts wrote:
> Perhaps I'm confusing things a bit.  Maybe mergepoints are just for merging
> HEAD to branch.

Right.

> Is any tagging needed when the branch gets merged to HEAD?
> (possibly a bit hypothetical as I realise I may never get that far).

Not really.  Normally, you'll just take the diff from the last
mergepoint to the branch tip, and apply that to HEAD, and declare the
branch dead - or declare the branch dead somewhat before that as the
patch gets reviewed, depending how it works out.

All this is much easier in non-CVS...

-- 
Daniel Jacobowitz
CodeSourcery

Re: New branch [was Re: RFC: MI output during program execution]

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 14 May 2006 13:23:40 +1200
> 
> I attach a compressed diff as its not as big as I had thought it would be.

Thanks.

You said at some point that manual changes are on your todo, but the
TODO file you sent doesn't mention that.  Please make sure the manual
changes are eventually included, because otherwise I will object to
merging this branch onto HEAD.  TIA.

Re: New branch [was Re: RFC: MI output during program execution]

[Nick Roberts]

 > You said at some point that manual changes are on your todo, but the
 > TODO file you sent doesn't mention that.  Please make sure the manual
 > changes are eventually included, because otherwise I will object to
 > merging this branch onto HEAD.  TIA.

Sorry, I meant it was on my todo list (lower case).  AFAIK Daniel was talking
about changing gdb+dejagnu to just gdb in gdbint.texi.  I was just saying
I hadn't forgotten that.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: New branch [was Re: RFC: MI output during program execution]

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 14 May 2006 21:13:27 +1200
> Cc: gdb-patches@sources.redhat.com
> 
>  > You said at some point that manual changes are on your todo, but the
>  > TODO file you sent doesn't mention that.  Please make sure the manual
>  > changes are eventually included, because otherwise I will object to
>  > merging this branch onto HEAD.  TIA.
> 
> Sorry, I meant it was on my todo list (lower case).  AFAIK Daniel was talking
> about changing gdb+dejagnu to just gdb in gdbint.texi.  I was just saying
> I hadn't forgotten that.

So does this mean you don't plan on modifying the manual to reflect
the changes on the async branch?

Re: New branch [was Re: RFC: MI output during program execution]

[Nick Roberts]

 > So does this mean you don't plan on modifying the manual to reflect
 > the changes on the async branch?

Not until I feel confident that the branch will actually make it back to
mainline.  Its probably a bit of a long shot, the previous partial
implementation showing that it can't be that easy.  I don't have enough
knowledge to tackle it on my own so I'm just trying to get the ball rolling
again.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

{PATCH] gdbint.texi [was Re: RFC: MI output during program execution]

[Nick Roberts]

 > >    cvs rtag nickrob-200604026-branchpoint gdb+dejagnu
 > 
 > Right.  You can just use the gdb module nowadays; the only difference
 > is that gdb+dejagnu will include tcl by accident.  Expect and DejaGNU
 > aren't in the tree any more.  Could I persuade you to update the
 > manual?

Actually I must have looked http://sourceware.org/gdb/current/ which still
refers to gdb+dejagnu, so need updating.

gdbint.texinfo uses gdb as a module name in the node "Versions and Branches"
but still refers to dejagnu elsewhere so I've tried to remove all those which
are inappropriate.  Andrew specifically refers to releases 5.0, 5.1 and 5.2 but
I've not tried to generalise this or update to more recent numbers but Joel
might like to do this as he goes through the process for GDB 6.5.

I've also changed a bit of punctuation and spelling.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2006-05-14  Nick Roberts  <nickrob@snap.net.nz>

	* gdbint.texinfo: Remove details for including DejaGnu.

*** gdbint.texinfo	24 Apr 2006 12:18:04 +1200	1.242
--- gdbint.texinfo	14 May 2006 18:26:44 +1200	
***************
*** 279,285 ****
  code starting from its entry point, and looks for instructions that
  allocate frame space, save the stack pointer in a frame pointer
  register, save registers, and so on.  Obviously, this can't be done
! accurately in general, but it's tractible to do well enough to be very
  helpful.  Prologue analysis predates the GNU toolchain's support for
  CFI; at one time, prologue analysis was the only mechanism
  @value{GDBN} used for stack unwinding at all, when the function
--- 279,285 ----
  code starting from its entry point, and looks for instructions that
  allocate frame space, save the stack pointer in a frame pointer
  register, save registers, and so on.  Obviously, this can't be done
! accurately in general, but it's tractable to do well enough to be very
  helpful.  Prologue analysis predates the GNU toolchain's support for
  CFI; at one time, prologue analysis was the only mechanism
  @value{GDBN} used for stack unwinding at all, when the function
***************
*** 405,411 ****
  
  @item
  It's easier to see that the analyzer is correct: you just see
! whether the analyzer properly (albiet conservatively) simulates
  the effect of each instruction.
  
  @item
--- 405,411 ----
  
  @item
  It's easier to see that the analyzer is correct: you just see
! whether the analyzer properly (albeit conservatively) simulates
  the effect of each instruction.
  
  @item
***************
*** 918,924 ****
  of open files and devices.
  
  There are a number of ways in which checkpoints may be implemented
! in gdb, eg. as corefiles, as forked processes, and as some opaque
  method implemented on the target side.
  
  A corefile can be used to save an image of target memory and register
--- 918,924 ----
  of open files and devices.
  
  There are a number of ways in which checkpoints may be implemented
! in gdb, e.g. as corefiles, as forked processes, and as some opaque
  method implemented on the target side.
  
  A corefile can be used to save an image of target memory and register
***************
*** 931,937 ****
  is used to implement checkpoints on Linux, and in principle might
  be used on other systems.
  
! Some targets, eg.@: simulators, might have their own built-in 
  method for saving checkpoints, and gdb might be able to take
  advantage of that capability without necessarily knowing any
  details of how it is done.
--- 931,937 ----
  is used to implement checkpoints on Linux, and in principle might
  be used on other systems.
  
! Some targets, e.g.@: simulators, might have their own built-in 
  method for saving checkpoints, and gdb might be able to take
  advantage of that capability without necessarily knowing any
  details of how it is done.
***************
*** 6026,6040 ****
  $  echo $u $V $D
  5.1 5_2 2002-03-03
  $  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -D $D-gmt gdb_$V-$D-branchpoint insight+dejagnu
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
! -D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight+dejagnu
  $  ^echo ^^
  ...
  $  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_$V-$D-branchpoint gdb_$V-branch insight+dejagnu
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight+dejagnu
  $  ^echo ^^
  ...
  $
--- 6026,6040 ----
  $  echo $u $V $D
  5.1 5_2 2002-03-03
  $  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -D $D-gmt gdb_$V-$D-branchpoint insight
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
! -D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight
  $  ^echo ^^
  ...
  $  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_$V-$D-branchpoint gdb_$V-branch insight
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight
  $  ^echo ^^
  ...
  $
***************
*** 6042,6057 ****
  
  @itemize @bullet
  @item
! by using @kbd{-D YYYY-MM-DD-gmt} the branch is forced to an exact
  date/time.
  @item
! the trunk is first taged so that the branch point can easily be found
  @item
! Insight (which includes GDB) and dejagnu are all tagged at the same time
  @item
! @file{version.in} gets bumped to avoid version number conflicts
  @item
! the reading of @file{.cvsrc} is disabled using @file{-f}
  @end itemize
  
  @subheading Update @file{version.in}
--- 6042,6057 ----
  
  @itemize @bullet
  @item
! By using @kbd{-D YYYY-MM-DD-gmt} the branch is forced to an exact
  date/time.
  @item
! The trunk is first tagged so that the branch point can easily be found.
  @item
! Insight which includes GDB is tagged at the same time.
  @item
! @file{version.in} gets bumped to avoid version number conflicts.
  @item
! The reading of @file{.cvsrc} is disabled using @file{-f}.
  @end itemize
  
  @subheading Update @file{version.in}
***************
*** 6079,6088 ****
  @itemize @bullet
  @item
  @file{0000-00-00} is used as a date to pump prime the version.in update
! mechanism
  @item
  @file{.90} and the previous branch version are used as fairly arbitrary
! initial branch version number
  @end itemize
  
  
--- 6079,6088 ----
  @itemize @bullet
  @item
  @file{0000-00-00} is used as a date to pump prime the version.in update
! mechanism.
  @item
  @file{.90} and the previous branch version are used as fairly arbitrary
! initial branch version number.
  @end itemize
  
  
***************
*** 6097,6105 ****
  
  @itemize @bullet
  @item
! a daily timestamp is added to the file @file{version.in}
  @item
! the new branch is included in the snapshot process
  @end itemize
  
  @noindent
--- 6097,6105 ----
  
  @itemize @bullet
  @item
! A daily timestamp is added to the file @file{version.in}.
  @item
! The new branch is included in the snapshot process.
  @end itemize
  
  @noindent
***************
*** 6140,6153 ****
  
  @itemize @bullet
  @item
! the branch tag
  @item
! how to check out the branch using CVS
  @item
! the date/number of weeks until the release
  @item
! the branch commit policy
! still holds.
  @end itemize
  
  @section Stabilize the branch
--- 6140,6152 ----
  
  @itemize @bullet
  @item
! The branch tag.
  @item
! How to check out the branch using CVS.
  @item
! The date/number of weeks until the release.
  @item
! The branch commit policy still holds.
  @end itemize
  
  @section Stabilize the branch
***************
*** 6206,6212 ****
  @subsubheading Check out the relevant modules:
  
  @smallexample
! $  for m in gdb insight dejagnu
  do
  ( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
  done
--- 6205,6211 ----
  @subsubheading Check out the relevant modules:
  
  @smallexample
! $  for m in gdb insight
  do
  ( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
  done
***************
*** 6250,6260 ****
  
  @itemize @bullet
  @item
! the version
  @item
! the update date
  @item
! who did it
  @end itemize
  
  @smallexample
--- 6249,6259 ----
  
  @itemize @bullet
  @item
! The version.
  @item
! The update date.
  @item
! Who did it.
  @end itemize
  
  @smallexample
***************
*** 6290,6313 ****
  $  cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog 
  @end smallexample
  
- @item dejagnu/src/dejagnu/configure.in
- 
- Dejagnu is more complicated.  The version number is a parameter to
- @code{AM_INIT_AUTOMAKE}.  Tweak it to read something like gdb-5.1.91.
- 
- Don't forget to re-generate @file{configure}.
- 
- Don't forget to include a @file{ChangeLog} entry.
- 
- @smallexample
- $  emacs dejagnu/src/dejagnu/configure.in
- ...
- c-x 4 a
- ...
- c-x c-s c-x c-c
- $  ( cd  dejagnu/src/dejagnu && autoconf )
- @end smallexample
- 
  @end table
  
  @subsubheading Do the dirty work
--- 6289,6294 ----
***************
*** 6319,6325 ****
  do
  ( cd $m/src && gmake -f src-release $m.tar )
  done
- $  ( m=dejagnu; cd $m/src && gmake -f src-release $m.tar.bz2 )
  @end smallexample
  
  If the top level source directory does not have @file{src-release}
--- 6300,6305 ----
***************
*** 6330,6336 ****
  do
  ( cd $m/src && gmake -f Makefile.in $m.tar )
  done
- $  ( m=dejagnu; cd $m/src && gmake -f Makefile.in $m.tar.bz2 )
  @end smallexample
  
  @subsubheading Check the source files
--- 6310,6315 ----
***************
*** 6365,6371 ****
  $  cp */src/*.tar .
  $  cp */src/*.bz2 .
  $  ls -F
! dejagnu/ dejagnu-gdb-5.2.tar.bz2 gdb/ gdb-5.2.tar insight/ insight-5.2.tar
  $  for m in gdb insight
  do
  bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
--- 6344,6350 ----
  $  cp */src/*.tar .
  $  cp */src/*.bz2 .
  $  ls -F
! gdb/ gdb-5.2.tar insight/ insight-5.2.tar
  $  for m in gdb insight
  do
  bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
***************
*** 6470,6481 ****
  This file, which is posted as the official announcement, includes:
  @itemize @bullet
  @item
! General announcement
  @item
  News.  If making an @var{M}.@var{N}.1 release, retain the news from
  earlier @var{M}.@var{N} release.
  @item
! Errata
  @end itemize
  
  @item htdocs/index.html
--- 6449,6460 ----
  This file, which is posted as the official announcement, includes:
  @itemize @bullet
  @item
! General announcement.
  @item
  News.  If making an @var{M}.@var{N}.1 release, retain the news from
  earlier @var{M}.@var{N} release.
  @item
! Errata.
  @end itemize
  
  @item htdocs/index.html
***************
*** 6484,6492 ****
  These files include:
  @itemize @bullet
  @item
! announcement of the most recent release
  @item
! news entry (remember to update both the top level and the news directory).
  @end itemize
  These pages also need to be regenerate using @code{index.sh}.
  
--- 6463,6471 ----
  These files include:
  @itemize @bullet
  @item
! Announcement of the most recent release.
  @item
! News entry (remember to update both the top level and the news directory).
  @end itemize
  These pages also need to be regenerate using @code{index.sh}.
  
***************
*** 6573,6580 ****
  @end smallexample
  
  Insight is used since that contains more of the release than
! @value{GDBN} (@code{dejagnu} doesn't get tagged but I think we can live
! with that).
  
  @subsubheading Mention the release on the trunk
  
--- 6552,6558 ----
  @end smallexample
  
  Insight is used since that contains more of the release than
! @value{GDBN}.
  
  @subsubheading Mention the release on the trunk
  
***************
*** 6627,6636 ****
  the available commands, and it has proven all too common for a change
  to cause a significant regression that went unnoticed for some time.
  
! The @value{GDBN} testsuite uses the DejaGNU testing framework.
! DejaGNU is built using @code{Tcl} and @code{expect}.  The tests
! themselves are calls to various @code{Tcl} procs; the framework runs all the
! procs and summarizes the passes and fails.
  
  @section Using the Testsuite
  
--- 6605,6613 ----
  the available commands, and it has proven all too common for a change
  to cause a significant regression that went unnoticed for some time.
  
! The @value{GDBN} testsuite uses the DejaGNU testing framework.  The
! tests themselves are calls to various @code{Tcl} procs; the framework
! runs all the procs and summarizes the passes and fails.
  
  @section Using the Testsuite
  

Re: {PATCH] gdbint.texi [was Re: RFC: MI output during program execution]

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 14 May 2006 18:34:37 +1200
> Cc: gdb-patches@sources.redhat.com
> 
> gdbint.texinfo uses gdb as a module name in the node "Versions and Branches"
> but still refers to dejagnu elsewhere so I've tried to remove all those which
> are inappropriate.  Andrew specifically refers to releases 5.0, 5.1 and 5.2 but
> I've not tried to generalise this or update to more recent numbers but Joel
> might like to do this as he goes through the process for GDB 6.5.
> 
> I've also changed a bit of punctuation and spelling.

Thanks.  This is okay, but please fix the following minor problems:

> 	* gdbint.texinfo: Remove details for including DejaGnu.

This needs to state every node in which you made a change.  (Nodes are
the Texinfo equivalents of C functions, as far as ChangeLog entries
are concerned.)

> ! in gdb, e.g. as corefiles, as forked processes, and as some opaque

There should be a @: after "e.g.", to signal TeX that the second
period does not end a sentence.

> ! By using @kbd{-D YYYY-MM-DD-gmt} the branch is forced to an exact
                                    ^
A comma is missing here.

> ! Insight which includes GDB is tagged at the same time.

Please use @value{GDBN} instead a literal GDB.  Also, please add a
comma after "Insight".

> ! gdb/ gdb-5.2.tar insight/ insight-5.2.tar

Please replace 5.2 with something more recent, or perhaps even some
future version (10.1, why not?).

Re: {PATCH] gdbint.texi

[Nick Roberts]

 > > gdbint.texinfo uses gdb as a module name in the node "Versions and
 > > Branches" but still refers to dejagnu elsewhere so I've tried to remove
 > > all those which are inappropriate.  Andrew specifically refers to
 > > releases 5.0, 5.1 and 5.2 but I've not tried to generalise this or update
 > > to more recent numbers but Joel might like to do this as he goes through
 > > the process for GDB 6.5.
 > > 
 > > I've also changed a bit of punctuation and spelling.
 > 
 > Thanks.  This is okay, but please fix the following minor problems:
 > 
 > > 	* gdbint.texinfo: Remove details for including DejaGnu.
 > 
 > This needs to state every node in which you made a change.  (Nodes are
 > the Texinfo equivalents of C functions, as far as ChangeLog entries
 > are concerned.)

OK, but I think there can be more slack with documentation, generally.  I
sometimes try to track down a bug through CVS but never a spelling mistake!

 >...

Punctuation added.

 > > ! gdb/ gdb-5.2.tar insight/ insight-5.2.tar
 > 
 > Please replace 5.2 with something more recent, or perhaps even some
 > future version (10.1, why not?).

For the reasons I gave at the top.  There is a precise relationship between
some of the numbers e.g "Create the branch":

 $  u=5.1
 $  v=5.2
 $  V=`echo $v | sed 's/\./_/g'`
 $  D=`date -u +%Y-%m-%d`
 $  echo $u $V $D
 5.1 5_2 2002-03-03

This goes beyond the purpose of my patch and will only serve to confuse if
I get it wrong, which I'm quite likely to do as I've never made a release.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2006-05-15  Nick Roberts  <nickrob@snap.net.nz>

	* gdbint.texinfo (Algorithms): Correct spellig and punctuation.
	(Releasing GDB, Testsuite): Remove details for including DejaGnu


*** gdbint.texinfo	24 Apr 2006 12:18:04 +1200	1.242
--- gdbint.texinfo	15 May 2006 09:44:17 +1200	
***************
*** 279,285 ****
  code starting from its entry point, and looks for instructions that
  allocate frame space, save the stack pointer in a frame pointer
  register, save registers, and so on.  Obviously, this can't be done
! accurately in general, but it's tractible to do well enough to be very
  helpful.  Prologue analysis predates the GNU toolchain's support for
  CFI; at one time, prologue analysis was the only mechanism
  @value{GDBN} used for stack unwinding at all, when the function
--- 279,285 ----
  code starting from its entry point, and looks for instructions that
  allocate frame space, save the stack pointer in a frame pointer
  register, save registers, and so on.  Obviously, this can't be done
! accurately in general, but it's tractable to do well enough to be very
  helpful.  Prologue analysis predates the GNU toolchain's support for
  CFI; at one time, prologue analysis was the only mechanism
  @value{GDBN} used for stack unwinding at all, when the function
***************
*** 405,411 ****
  
  @item
  It's easier to see that the analyzer is correct: you just see
! whether the analyzer properly (albiet conservatively) simulates
  the effect of each instruction.
  
  @item
--- 405,411 ----
  
  @item
  It's easier to see that the analyzer is correct: you just see
! whether the analyzer properly (albeit conservatively) simulates
  the effect of each instruction.
  
  @item
***************
*** 918,924 ****
  of open files and devices.
  
  There are a number of ways in which checkpoints may be implemented
! in gdb, eg. as corefiles, as forked processes, and as some opaque
  method implemented on the target side.
  
  A corefile can be used to save an image of target memory and register
--- 918,924 ----
  of open files and devices.
  
  There are a number of ways in which checkpoints may be implemented
! in gdb, e.g.@: as corefiles, as forked processes, and as some opaque
  method implemented on the target side.
  
  A corefile can be used to save an image of target memory and register
***************
*** 931,937 ****
  is used to implement checkpoints on Linux, and in principle might
  be used on other systems.
  
! Some targets, eg.@: simulators, might have their own built-in 
  method for saving checkpoints, and gdb might be able to take
  advantage of that capability without necessarily knowing any
  details of how it is done.
--- 931,937 ----
  is used to implement checkpoints on Linux, and in principle might
  be used on other systems.
  
! Some targets, e.g.@: simulators, might have their own built-in 
  method for saving checkpoints, and gdb might be able to take
  advantage of that capability without necessarily knowing any
  details of how it is done.
***************
*** 6026,6040 ****
  $  echo $u $V $D
  5.1 5_2 2002-03-03
  $  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -D $D-gmt gdb_$V-$D-branchpoint insight+dejagnu
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
! -D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight+dejagnu
  $  ^echo ^^
  ...
  $  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_$V-$D-branchpoint gdb_$V-branch insight+dejagnu
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight+dejagnu
  $  ^echo ^^
  ...
  $
--- 6026,6040 ----
  $  echo $u $V $D
  5.1 5_2 2002-03-03
  $  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -D $D-gmt gdb_$V-$D-branchpoint insight
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
! -D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight
  $  ^echo ^^
  ...
  $  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_$V-$D-branchpoint gdb_$V-branch insight
  cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
! -b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight
  $  ^echo ^^
  ...
  $
***************
*** 6042,6057 ****
  
  @itemize @bullet
  @item
! by using @kbd{-D YYYY-MM-DD-gmt} the branch is forced to an exact
  date/time.
  @item
! the trunk is first taged so that the branch point can easily be found
  @item
! Insight (which includes GDB) and dejagnu are all tagged at the same time
  @item
! @file{version.in} gets bumped to avoid version number conflicts
  @item
! the reading of @file{.cvsrc} is disabled using @file{-f}
  @end itemize
  
  @subheading Update @file{version.in}
--- 6042,6057 ----
  
  @itemize @bullet
  @item
! By using @kbd{-D YYYY-MM-DD-gmt}, the branch is forced to an exact
  date/time.
  @item
! The trunk is first tagged so that the branch point can easily be found.
  @item
! Insight, which includes @value{GDBN}, is tagged at the same time.
  @item
! @file{version.in} gets bumped to avoid version number conflicts.
  @item
! The reading of @file{.cvsrc} is disabled using @file{-f}.
  @end itemize
  
  @subheading Update @file{version.in}
***************
*** 6079,6088 ****
  @itemize @bullet
  @item
  @file{0000-00-00} is used as a date to pump prime the version.in update
! mechanism
  @item
  @file{.90} and the previous branch version are used as fairly arbitrary
! initial branch version number
  @end itemize
  
  
--- 6079,6088 ----
  @itemize @bullet
  @item
  @file{0000-00-00} is used as a date to pump prime the version.in update
! mechanism.
  @item
  @file{.90} and the previous branch version are used as fairly arbitrary
! initial branch version number.
  @end itemize
  
  
***************
*** 6097,6105 ****
  
  @itemize @bullet
  @item
! a daily timestamp is added to the file @file{version.in}
  @item
! the new branch is included in the snapshot process
  @end itemize
  
  @noindent
--- 6097,6105 ----
  
  @itemize @bullet
  @item
! A daily timestamp is added to the file @file{version.in}.
  @item
! The new branch is included in the snapshot process.
  @end itemize
  
  @noindent
***************
*** 6140,6153 ****
  
  @itemize @bullet
  @item
! the branch tag
  @item
! how to check out the branch using CVS
  @item
! the date/number of weeks until the release
  @item
! the branch commit policy
! still holds.
  @end itemize
  
  @section Stabilize the branch
--- 6140,6152 ----
  
  @itemize @bullet
  @item
! The branch tag.
  @item
! How to check out the branch using CVS.
  @item
! The date/number of weeks until the release.
  @item
! The branch commit policy still holds.
  @end itemize
  
  @section Stabilize the branch
***************
*** 6206,6212 ****
  @subsubheading Check out the relevant modules:
  
  @smallexample
! $  for m in gdb insight dejagnu
  do
  ( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
  done
--- 6205,6211 ----
  @subsubheading Check out the relevant modules:
  
  @smallexample
! $  for m in gdb insight
  do
  ( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
  done
***************
*** 6250,6260 ****
  
  @itemize @bullet
  @item
! the version
  @item
! the update date
  @item
! who did it
  @end itemize
  
  @smallexample
--- 6249,6259 ----
  
  @itemize @bullet
  @item
! The version.
  @item
! The update date.
  @item
! Who did it.
  @end itemize
  
  @smallexample
***************
*** 6290,6313 ****
  $  cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog 
  @end smallexample
  
- @item dejagnu/src/dejagnu/configure.in
- 
- Dejagnu is more complicated.  The version number is a parameter to
- @code{AM_INIT_AUTOMAKE}.  Tweak it to read something like gdb-5.1.91.
- 
- Don't forget to re-generate @file{configure}.
- 
- Don't forget to include a @file{ChangeLog} entry.
- 
- @smallexample
- $  emacs dejagnu/src/dejagnu/configure.in
- ...
- c-x 4 a
- ...
- c-x c-s c-x c-c
- $  ( cd  dejagnu/src/dejagnu && autoconf )
- @end smallexample
- 
  @end table
  
  @subsubheading Do the dirty work
--- 6289,6294 ----
***************
*** 6319,6325 ****
  do
  ( cd $m/src && gmake -f src-release $m.tar )
  done
- $  ( m=dejagnu; cd $m/src && gmake -f src-release $m.tar.bz2 )
  @end smallexample
  
  If the top level source directory does not have @file{src-release}
--- 6300,6305 ----
***************
*** 6330,6336 ****
  do
  ( cd $m/src && gmake -f Makefile.in $m.tar )
  done
- $  ( m=dejagnu; cd $m/src && gmake -f Makefile.in $m.tar.bz2 )
  @end smallexample
  
  @subsubheading Check the source files
--- 6310,6315 ----
***************
*** 6365,6371 ****
  $  cp */src/*.tar .
  $  cp */src/*.bz2 .
  $  ls -F
! dejagnu/ dejagnu-gdb-5.2.tar.bz2 gdb/ gdb-5.2.tar insight/ insight-5.2.tar
  $  for m in gdb insight
  do
  bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
--- 6344,6350 ----
  $  cp */src/*.tar .
  $  cp */src/*.bz2 .
  $  ls -F
! gdb/ gdb-5.2.tar insight/ insight-5.2.tar
  $  for m in gdb insight
  do
  bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
***************
*** 6470,6481 ****
  This file, which is posted as the official announcement, includes:
  @itemize @bullet
  @item
! General announcement
  @item
  News.  If making an @var{M}.@var{N}.1 release, retain the news from
  earlier @var{M}.@var{N} release.
  @item
! Errata
  @end itemize
  
  @item htdocs/index.html
--- 6449,6460 ----
  This file, which is posted as the official announcement, includes:
  @itemize @bullet
  @item
! General announcement.
  @item
  News.  If making an @var{M}.@var{N}.1 release, retain the news from
  earlier @var{M}.@var{N} release.
  @item
! Errata.
  @end itemize
  
  @item htdocs/index.html
***************
*** 6484,6492 ****
  These files include:
  @itemize @bullet
  @item
! announcement of the most recent release
  @item
! news entry (remember to update both the top level and the news directory).
  @end itemize
  These pages also need to be regenerate using @code{index.sh}.
  
--- 6463,6471 ----
  These files include:
  @itemize @bullet
  @item
! Announcement of the most recent release.
  @item
! News entry (remember to update both the top level and the news directory).
  @end itemize
  These pages also need to be regenerate using @code{index.sh}.
  
***************
*** 6573,6580 ****
  @end smallexample
  
  Insight is used since that contains more of the release than
! @value{GDBN} (@code{dejagnu} doesn't get tagged but I think we can live
! with that).
  
  @subsubheading Mention the release on the trunk
  
--- 6552,6558 ----
  @end smallexample
  
  Insight is used since that contains more of the release than
! @value{GDBN}.
  
  @subsubheading Mention the release on the trunk
  
***************
*** 6627,6636 ****
  the available commands, and it has proven all too common for a change
  to cause a significant regression that went unnoticed for some time.
  
! The @value{GDBN} testsuite uses the DejaGNU testing framework.
! DejaGNU is built using @code{Tcl} and @code{expect}.  The tests
! themselves are calls to various @code{Tcl} procs; the framework runs all the
! procs and summarizes the passes and fails.
  
  @section Using the Testsuite
  
--- 6605,6613 ----
  the available commands, and it has proven all too common for a change
  to cause a significant regression that went unnoticed for some time.
  
! The @value{GDBN} testsuite uses the DejaGNU testing framework.  The
! tests themselves are calls to various @code{Tcl} procs; the framework
! runs all the procs and summarizes the passes and fails.
  
  @section Using the Testsuite
  

Re: {PATCH] gdbint.texi

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Tue, 16 May 2006 10:06:06 +1200
> Cc: gdb-patches@sources.redhat.com
> 
>  > > 	* gdbint.texinfo: Remove details for including DejaGnu.
>  > 
>  > This needs to state every node in which you made a change.  (Nodes are
>  > the Texinfo equivalents of C functions, as far as ChangeLog entries
>  > are concerned.)
> 
> OK, but I think there can be more slack with documentation, generally.

Yes, but is there a real problem here?  How many nodes did you update,
anyway?

Re: New branch [was Re: RFC: MI output during program execution]

[PAUL GILLIAM]

On Fri, 2006-05-12 at 22:28 -0400, Daniel Jacobowitz wrote:
> On Sun, May 14, 2006 at 01:23:40PM +1200, Nick Roberts wrote:
> > Perhaps I'm confusing things a bit.  Maybe mergepoints are just for merging
> > HEAD to branch.
> 
> Right.
> 
> > Is any tagging needed when the branch gets merged to HEAD?
> > (possibly a bit hypothetical as I realise I may never get that far).
> 
> Not really.  Normally, you'll just take the diff from the last
> mergepoint to the branch tip, and apply that to HEAD, and declare the
> branch dead - or declare the branch dead somewhat before that as the
> patch gets reviewed, depending how it works out.
> 
> All this is much easier in non-CVS...
> 

Is it time again to talk about SVN?