This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Beyond GCC 3.0
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: Beyond GCC 3.0
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Fri, 29 Jun 2001 19:55:22 +0100 (BST)
- cc: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>
On Thu, 28 Jun 2001, Mark Mitchell wrote:
> Even now, anyone can start a branch for just about any purpose. The only
> constraint is that check-ins on the branch must have copyright assignments,
> same as anything else. But, if you want to work on rewriting the ia64
> back-end, which might not be your area of expertise, you can start on
> a branch and work away for six months, and then ask to have it approved.
So, copyright assignments are required for checkins on branches, but not
patent licences?
OK to commit the following patch to document that anyone can create a
branch? (Someone familiar with handling branches in CVS ought to add
examples of creating and merging to/from them, where I just noted the need
for branchpoint tags.)
Index: cvswrite.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/cvswrite.html,v
retrieving revision 1.39
diff -u -r1.39 cvswrite.html
--- cvswrite.html 2001/05/11 13:36:45 1.39
+++ cvswrite.html 2001/06/29 18:52:05
@@ -20,6 +20,7 @@
<li><a href="#policies">Write access policies</a></li>
<li><a href="#checkin">Checking in a change</a></li>
<li><a href="#example">Example check-in session</a></li>
+ <li><a href="#branches">Creating branches</a></li>
</ol>
<hr>
@@ -124,6 +125,12 @@
Such files would include <code>config.guess</code> and
<code>config.sub</code>.</p>
+<p>Any maintainer with CVS write access may <a href="#branches">create
+and use a branch</a> for development, including outside the parts of
+the compiler they maintain, 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.</p>
+
<hr>
<h2><a name="checkin">Checking in a change</a></h2>
@@ -391,6 +398,12 @@
you should check them in with separate cvs commit commands.</p>
<p>And that's it!</p>
+
+<hr>
+<h2><a name="branches">Creating branches</a></h2>
+
+<p>When creating a branch for development, you should first tag the
+branchpoint.</p>
</body>
</html>
--
Joseph S. Myers
jsm28@cam.ac.uk