This page was produced by an automated import process, and may have formatting errors; feel free to fix.

Experimental Branches


GDB permits the creation of branches, cut from the CVS repository, for experimental development. Branches make it possible for developers to share preliminary work, and maintainers to examine significant new developments.

The following are a set of guidelines for creating such branches:

''a branch has an owner''

The owner can set further policy for a branch, but may not change the ground rules. In particular, they can set a policy for commits (be it adding more reviewers or deciding who can commit).

''all commits are posted''

All changes committed to a branch shall also be posted to [ the GDB patches mailing list]. While commentary on such changes are encouraged, people should remember that the changes only apply to a branch.

''all commits are covered by an assignment''

This ensures that all changes belong to the Free Software Foundation, and avoids the possibility that the branch may become contaminated.

''a branch is focused''

A focused branch has a single objective or goal, and does not contain unnecessary or irrelevant changes. Cleanups, where identified, being be pushed into the mainline as soon as possible.

''a branch tracks mainline''

This keeps the level of divergence under control. It also keeps the pressure on developers to push cleanups and other stuff into the mainline.

''a branch shall contain the entire GDB module''

The GDB module gdb should be specified when creating a branch (branches of individual files should be avoided). See [#Tags Tags].

''a branch shall be branded using {{{}}}''

The file gdb/ shall be modified so that it identifies the branch owner and branch name, e.g., ‘’ or ‘6.2 (Owner Name)’.


To simplify the identification of GDB branches, the following branch tagging convention is strongly recommended:

The branch point and corresponding branch tag. YYYYMMDD is the date that the branch was created. A branch is created using the sequence: [experimental-branch-tags ]

cvs rtag ''owner''_''name''-''YYYYMMDD''-branchpoint gdb
cvs rtag -b -r ''owner''_''name''-''YYYYMMDD''-branchpoint \
   ''owner''_''name''-''YYYYMMDD''-branch gdb

The tagged point, on the mainline, that was used when merging the branch on yyyymmdd. To merge in all changes since the branch was cut, use a command sequence like:

cvs rtag ''owner''_''name''-''yyyymmdd''-mergepoint gdb
cvs update \

Similar sequences can be used to just merge in changes since the last merge.

For further information on CVS, see [ Concurrent Versions System].

None: Internals Experimental-Branches (last edited 2013-08-20 23:40:43 by StanShebs)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.