We have read/write access to the SVN repository available for maintainers and significant developers.
Our web pages are managed via CVS.
We provide authenticated access via the SSH protocol. This needs to be sponsored by an existing maintainer (someone with "write after approval" is not sufficient).
If you already have an account on sourceware.org/gcc.gnu.org, ask
firstname.lastname@example.org to add access to the GCC repository.
Include the name of your sponsor and CC: her.
If you do not have an account yet, use this form,
again specifying your sponsor.
We will then provision you on
gcc.gnu.org and inform you by mail. At this point,
check out a tree using the instructions below and add yourself
to the MAINTAINERS file. Note: Your first and last names must
be exactly the same between your account on gcc.gnu.org and the
MAINTAINERS file. Place your name in the correct section following
the conventions specified in the file (e.g. "Write After Approval"
is "last name alphabetical order").
Then produce a diff to that file and circulate it to the
gcc-patches list, whilst also checking in your change to
test write access (approval from the mailing list is not needed in this
one case). For all other changes, please be sure to follow the write
access policies below.
Once your account has been set up, check out the GCC sources by issuing the command:
svn co svn+ssh://email@example.com/svn/gcc/trunk gcc
where username is your user name at gcc.gnu.org.
It is also possible to convert an existing SVN tree to use SSH by
svn switch --relocate:
svn switch --relocate svn://gcc.gnu.org/svn/gcc svn+ssh://firstname.lastname@example.org/svn/gcc
To avoid the nuisance of having to supply your passphrase for each
operation, you may want to use
To avoid messages about (lack of) X11 forwarding, put in your $HOME/.ssh/config an entry like:
The GCC project grants developers various levels of write access to and review authority over the GCC master sources. We have not put any technical enforcement in place, rather we rely on everyone to follow the appropriate policies.
A limited number of developers have global review permission and can approve other people's changes to any part of the compiler.
This is for people who have primary responsibility for ports, front ends, or other specific aspects of the compiler. These folks are allowed to make changes to areas they maintain and related documentation, web pages, and test cases (and target conditionals) without approval from anyone else, and approve other people's changes in those areas. They must get approval for changes elsewhere in the compiler.
Maintainers of a port maintain the relevant files in
gcc/config, documentation, web pages, and test cases
and aspects of these relevant to that port. Port maintainers do
not have approval rights beyond this.
This is similar to localized write permission, except that reviewers required approval for their own changes.
This is folks that make regular contributions, but do not fall into one of the previous categories. People with write after approval need to submit their patches to the list; once the patches have been approved by the appropriate maintainers the patches may be checked in. The steering committee or a well-established GCC maintainer (including reviewers) can approve for write access any person with GNU copyright assignment papers in place and known to submit good patches.
The list of folks with write access to the repository can be found in the MAINTAINERS file in the GCC distribution.
When you have checked in a patch exactly as it has been approved, you do not need to tell that to people -- including the approver. People interested in when a particular patch is committed can check SVN or the gcc-cvs list.
The following changes can be made by everyone with SVN write access:
Obvious fixes can be committed without prior approval. Just check
in the fix and copy it to
gcc-patches. A good test to
determine whether a fix is obvious:
will the person who objects to
my work the most be able to find a fault with my fix? If the fix
is later found to be faulty, it can always be rolled back. We don't
want to get overly restrictive about checkin policies.
Similarly, no outside approval is needed to revert a patch that you checked in.
Importing files maintained outside the tree from their official versions.
Creating and using a branch for development, including outside the parts of the compiler one maintains, provided that changes on the branch have copyright assignments on file. Merging such developments back to the mainline still needs approval in the usual way.
All changes must be tested according to the instructions for testing patches before they are checked in. If you wrote the patch yourself, you should test it yourself, unless there is a reason why someone else must do it for you (for instance, if you are fixing a problem on a system you do not have access to). If you are checking in a patch for someone else, you only need to test it if they did not.
You must test exactly the change you intend to check in; it is not good enough to have tested an earlier variant. (Unless the only changes from the earlier variant are formatting and comment changes; if there are any changes to the code itself you should re-bootstrap.) It is a good idea to re-test patches which were submitted a long time ago before applying them, even if nothing appears to have changed.
When you post your change to
gcc-patches, state the
canonical name(s) of the platform(s) you used for testing.
These rules are designed to ensure that checked-in code does not contain bugs that prevent other people from continuing to get their work done. There will always be bugs, but these rules help to minimize the amount of time where the tree does not build at all. Repeated failure to adhere to these rules could result in the revocation of check-in privileges by the Steering Committee.
The following is meant to provide a very quick overview of how to check in a change. It is not meant to be a replacement for the SVN manual but instead a supplement. The SVN manual is available both as part of the SVN source distribution, as well as at the book Version Control with Subversion.
In all the commands listed below, you can give an explicit list of filenames to the SVN command. We recommend you list files explicitly when performing checkins to avoid accidental checkins of local code.
We prefer that each SVN checkin be of a complete, single logical change, which may affect multiple files. The log message for that checkin should be the complete ChangeLog entry for the change. This makes it easier to correlate changes across files, and minimizes the time the repository is inconsistent. If you have several unrelated changes, you should check them in with separate SVN commit commands.
svn update" before attempting a checkin; this will save you a little time if someone else has modified that file since the last time you synced your sources. It will also identify any files in your local tree that you have modified.
svn diff" after applying a patch to a local tree. Review the output to make sure that only the changes you wanted to check in will be checked in. Also check to see if the copyright dates need to be updated.
svn commit" to check in the patch. You can enter the log message via the "
-m" argument to commit, or wait for the editor window to appear and enter the log message in the editor window.
Here's an actual check-in session for a patch John Carr recently sent to the GCC list. This was the ChangeLog for his change:
Sun Feb 8 08:02:13 1998 John Carr <email@example.com> * bitmap.c (bitmap_debug_file): HOST_PTR_PRINTF converts a pointer, not a HOST_WIDE_INT. * calls.c (expand_call): Change test of expand_inline_function return value to stop compiler warning. * genattrtab.c (RTL_HASH): Cast pointer to long, not HOST_WIDE_INT.
[/law/gcc] svn update ? libobjc ? gcc/.ada ? gcc/jump.c.SAVE ? gcc/loop.c.SAVE M MAINTAINERS M Makefile.in M gcc/loop.c M gcc/cp/parse.c M gcc/objc/Make-lang.in M gcc/objc/Makefile.in At revision 105932
The question marks indicate files in my local repository that are not part of the official sources. The "M" indicates files I've changed locally for some unrelated work -- thus I have to be careful to avoid checking them in. A "U" would have indicated a file that SVN updated because my local copy was out of date relative to the master sources.
The local repository is now up to date.
[/law/gcc/gcc] patch < ~/Mail/gcc/pendingpatches/42 Hmm... Looks like a new-style context diff to me... The text leading up to this was: [ uninteresting text deleted ] |*** bitmap.c.egcs Sat Dec 20 06:31:11 1997 |--- bitmap.c Sun Feb 8 08:01:32 1998 -------------------------- Patching file bitmap.c using Plan A... Hunk #1 succeeded at 563. Hunk #2 succeeded at 573. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** calls.c.egcs Sun Feb 8 07:44:02 1998 |--- calls.c Sun Feb 8 08:00:08 1998 -------------------------- Patching file calls.c using Plan A... Hunk #1 succeeded at 730. Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** genattrtab.c.egcs Sun Feb 8 07:44:04 1998 |--- genattrtab.c Sun Feb 8 08:05:36 1998 -------------------------- Patching file genattrtab.c using Plan A... Hunk #1 succeeded at 506. done
ChangeLog entries should be handled as straight text; patches against ChangeLogs rarely apply correctly.
The patch and its associated
ChangeLog entry are in my
local tree; now I run
svn diff on the modified files and
review the output, verifying that it only contains the changes we want.
[/law/gcc/gcc] svn diff bitmap.c calls.c genattrtab.c
Review the changed files to see if any copyrights need updating, in this particular case all three needed their copyrights updated.
[/law/gcc/gcc] vi bitmap.c calls.c genattrtab.c
[/law/gcc/gcc] svn commit ChangeLog bitmap.c calls.c genattrtab.c
My editor starts and I enter the log message; the lines starting
This line, and those below, will be ignored are automatically
added by SVN and will be automatically removed:
* bitmap.c (bitmap_debug_file): HOST_PTR_PRINTF converts a pointer, not a HOST_WIDE_INT. * calls.c (expand_call): Change test of expand_inline_function return value to stop compiler warning. * genattrtab.c (RTL_HASH): Cast pointer to long, not HOST_WIDE_INT. --This line, and those below, will be ignored-- M ChangeLog M bitmap.c M calls.c M genattrtab.c
Now write & quit from the editor, and SVN will start the actual checkin process....
Sending ChangeLog Sending bitmap.c Sending calls.c Sending genattrtab.c Transmitting file data . Committed revision 105933. [/law/gcc/gcc]
And that's it!
To create a branch for development, simply copy the trunk directory to a directory in /branches as follows:
svn cp svn+ssh://firstname.lastname@example.org/svn/gcc/trunk \ svn+ssh://email@example.com/svn/gcc/branches/$BRANCH
Also, please document such branches at the list of development branches.
When merging changes from mainline (or another branch) to a branch, do not copy the entire set of ChangeLog entries. Just use something like "Merge from mainline" or similar.
Your gcc.gnu.org account also receives e-mail (and is what you use for Bugzilla). If you ever need to change the address e-mail to firstname.lastname@example.org is forwarded to, you can easily do so using
ssh email@example.com email firstname.lastname@example.org
Similarly if you want to add a new SSH key to your account:
ssh email@example.com appendkey < KEYFILE
Or replace all your SSH keys:
ssh firstname.lastname@example.org replacekey < KEYFILE
Copyright (C) Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.