jvanzyl 01/05/18 09:55:51
Modified: xdocs branches.xml
xdocs/stylesheets project.xml
Log:
- adding blurb about how to checkout branches in development.
Revision Changes Path
1.7 +82 -50 jakarta-turbine/xdocs/branches.xml
Index: branches.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine/xdocs/branches.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- branches.xml 2001/05/13 04:29:09 1.6
+++ branches.xml 2001/05/18 16:55:49 1.7
@@ -12,68 +12,78 @@
<section name="CVS Branches">
<p>
-The branches are a feature of CVS that allows the development to be partitioned
-so that one stream does not affect the other. They prove to be useful, when
-there is a need to perform modifications that are hard to perform as a
-consecutive gradual transitions that work well in the usual course of
-development. When files that are depended upon by numerous other files need to
-be substantially changed all the other would have to be modified along with
-them. That would require that a lone developer performs all these changes in his
-own snapshot and then checks them all in, causing the sources to leap forward.
-As Turbine grows, situations arise that this is no longer possible. It's good to
-have version control on the gradual changes as opposed to quantum-leap changes.
-It's also important to have the larges set of eyes possible looking at the code
-as soon as possible. On the other hand, we strive to keep Turbine CVS tree
-compilable and working at all times. This calls for usage of branches whenever
-vast modifications of the sources are needed.
+
+ The branches are a feature of CVS that allows the development to be partitioned
+ so that one stream does not affect the other. They prove to be useful, when
+ there is a need to perform modifications that are hard to perform as a
+ consecutive gradual transitions that work well in the usual course of
+ development. When files that are depended upon by numerous other files need to
+ be substantially changed all the other would have to be modified along with
+ them. That would require that a lone developer performs all these changes in his
+ own snapshot and then checks them all in, causing the sources to leap forward.
+ As Turbine grows, situations arise that this is no longer possible. It's good to
+ have version control on the gradual changes as opposed to quantum-leap changes.
+ It's also important to have the larges set of eyes possible looking at the code
+ as soon as possible. On the other hand, we strive to keep Turbine CVS tree
+ compilable and working at all times. This calls for usage of branches whenever
+ vast modifications of the sources are needed.
+
</p>
<p>
-The <a href="http://www.red-bean.com/cvsbook/";>CVS book</a> describes multiple
-approaches to performing development using branches. We decided that the
-simplest approach called <em>Flying Fish technique</em> will fit our needs best.
-It involves creating a branch when there is a need for a separate thread of
-development, and abandoning the branch once all the changes are merged with the
-trunk. If need arises for separated develompent on the same subject, a brand new
-branch is creted. This saves us the additional complexity of merging changes
-back and forth between the trunk and the branches and keeping track of what was
-merged into where. We want the things to be as simple as possible.
+
+ The <a href="http://www.red-bean.com/cvsbook/";>CVS book</a> describes multiple
+ approaches to performing development using branches. We decided that the
+ simplest approach called <em>Flying Fish technique</em> will fit our needs best.
+ It involves creating a branch when there is a need for a separate thread of
+ development, and abandoning the branch once all the changes are merged with the
+ trunk. If need arises for separated develompent on the same subject, a brand new
+ branch is creted. This saves us the additional complexity of merging changes
+ back and forth between the trunk and the branches and keeping track of what was
+ merged into where. We want the things to be as simple as possible.
+
</p>
<p>
-The naming scheme used for the branches is as following: The name of the branch
-is composed of a name describing the subject being worked on, followed by an
-underscore and a two digit number used to distinguish multiple branches for the
-same subject.<br/>
-
-Actual tag names are then:<br/>
-<em>subject</em>_<em>number</em>-sprout for marking the revision of the trunk
-where the branch diverged <br/>
-<em>subject</em>_<em>number</em>-branch for the branch itself <br/>
-<em>subject</em>_<em>numner</em>-before-merge for marking the last revision of
-files before merging in the branch <br/>
-<em>subject</em>_<em>number</em>-merge for marking the revision of the trunk
-with changes made on the branch merged in <br/>
+
+ The naming scheme used for the branches is as following: The name of the branch
+ is composed of a name describing the subject being worked on, followed by an
+ underscore and a two digit number used to distinguish multiple branches for the
+ same subject.<br/>
+
+ Actual tag names are then:<br/>
+ <em>subject</em>_<em>number</em>-sprout for marking the revision of the trunk
+ where the branch diverged <br/>
+ <em>subject</em>_<em>number</em>-branch for the branch itself <br/>
+ <em>subject</em>_<em>numner</em>-before-merge for marking the last revision of
+ files before merging in the branch <br/>
+ <em>subject</em>_<em>number</em>-merge for marking the revision of the trunk
+ with changes made on the branch merged in <br/>
+
</p>
<p>
-Below, you can find a list of branches that were used during the development of
-Turbine. The 'coordinating person' is responsible for exchange of information
-between developers, maintaing the branches' TODO and timely merging the changes
-into the trunk (closing the branch). The shorter a branch stays outside the
-trunk, the better, because that decrases the number of conflict that will arise
-while merging back. Developers that are working on the trunk of the CVS should
-not make modifications to the code named in 'affected sources' to prevent
-merging conflicts. Instead, they should direct all requests / patches to the
-coordinating person. Developers wishing to join the development of the branching
-code, should contact the coordinating person.
+
+ Below, you can find a list of branches that were used during the development of
+ Turbine. The 'coordinating person' is responsible for exchange of information
+ between developers, maintaing the branches' TODO and timely merging the changes
+ into the trunk (closing the branch). The shorter a branch stays outside the
+ trunk, the better, because that decrases the number of conflict that will arise
+ while merging back. Developers that are working on the trunk of the CVS
should
+ not make modifications to the code named in 'affected sources' to prevent
+ merging conflicts. Instead, they should direct all requests / patches to the
+ coordinating person. Developers wishing to join the development of the branching
+ code, should contact the coordinating person.
+
</p>
<p>
-If you wish to learn more about branches, download the CVS book at
-<a href="http://www.red-bean.com/cvsbook/";>Red Bean.com</a>, or browse a
-<a href="http://www.durak.org/cvswebsites/doc/cvs_5.php3#SEC54";>CVS manual</a>
-online.
+
+ If you wish to learn more about branches, download the CVS book at
+ <a href="http://www.red-bean.com/cvsbook/";>Red Bean.com</a>, or browse a
+ <a href="http://www.durak.org/cvswebsites/doc/cvs_5.php3#SEC54";>CVS manual</a>
+ online.
+
</p>
</section>
@@ -145,6 +155,28 @@
<td>All sources</td>
</tr>
</table>
+
+<p>
+
+ You can check out any of the open branches listed above.
+ For example, if you wish to look at the source for the 2.1
+ branch then you would use the following command:
+
+</p>
+
+<source>
+
+ cvs co -d jakarta-turbine-2.1 -r T_2_1_BRANCH jakarta-turbine
+
+</source>
+
+<p>
+
+ This will check out the turbine 2.1 branch into a directory
+ called 'jakarta-turbine-2.1' so that it won't interfere with
+ the HEAD branch.
+
+</p>
</section>
1.31 +1 -1 jakarta-turbine/xdocs/stylesheets/project.xml
Index: project.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine/xdocs/stylesheets/project.xml,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- project.xml 2001/05/18 16:24:56 1.30
+++ project.xml 2001/05/18 16:55:50 1.31
@@ -27,7 +27,6 @@
<menu name="Documentation">
<item name="Turbine Documentation"
href="/turbine-documentation-project.html"/>
<item name="Core Schema" href="/turbine-schema.html"/>
- <item name="DB Adapters" href="/db-adapters.html"/>
<item name="J2EE Integration" href="/j2ee-integration.html"/>
<item name="Model 2+1" href="/model2+1.html"/>
<item name="Pull MVC Model" href="/pullmodel.html"/>
@@ -57,6 +56,7 @@
<item name="Changes" href="/changes.html"/>
<item name="Coding Specification" href="/code-standards.html"/>
<item name="CVS Branches" href="/branches.html"/>
+ <item name="DB Adapters" href="/db-adapters.html"/>
<item name="Deprecation Rules" href="/deprecation.html"/>
<item name="Project Map" href="/project-map.html"/>
<item name="Proposals" href="/proposals.html"/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
