User: starksm Date: 01/06/15 08:51:56 Modified: . cvs.jsp Added: . CVSAdmin.html Log: Added the CVS admin policies document to the cvs.jsp page Revision Changes Path 1.2 +64 -61 newsite/cvs.jsp Index: cvs.jsp =================================================================== RCS file: /cvsroot/jboss/newsite/cvs.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- cvs.jsp 2001/06/14 17:33:38 1.1 +++ cvs.jsp 2001/06/15 15:51:56 1.2 @@ -1,61 +1,64 @@ -<jsp:include page="head.jsp" flush="true" /> -<jsp:include page="slogan.jsp" flush="true" > - <jsp:param name="SLOGAN" value="SOURCE CODE AND CVS"/> -</jsp:include> - - - - <!-- CONTENT --> - <p class="head">JBOSS IS DEVELOPED PUBLICLY - <p class="text">JBoss is a free implementation of the J2EE interfaces from SUN. Our code is co-developed and the source is freely available. You - can either get the code in a zip format to browse it or, if you - plan on working with the source tree, you can set up a CVS environment - on your machine. - - <p class="text">We thank sourceforge.net for hosting our CVS. <A href="http://sourceforge.net";> <IMG src="http://sourceforge.net/sflogo.php?group_id=22866"; width="88" height="31" border="0" alt="SourceForge Logo"></A> - <p class="head">SOURCE CODE - <p class="text"><a class="link" href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/";><font face="Myriad Web,Arial"><b>Browse the source on-line</b></font></a> - <br>Download a daily updated <a class="link" href="/zip_archives/">snapshot of the sources</a> (ZIP archive) - - <p class="head">CVS ENVIRONMENT - <p class="text">To browse the source tree you <b>will need a CVS client</b>. If you don't have one already installed on your machine you can download <a class="link" href="http://www.jcvs.org/";>jCVS</a>, the CVS client in java. jCVS will work on any platform including Linux. However we recommend the native Linux tools or try <a class="link" href="http://www.wincvs.org";>winCVS</a> if you are based on a win32 platform. - <p><b>Settings for anonymous browsing:</b></p> - <p>CVSROOT is <br> - :pserver:[EMAIL PROTECTED]:/cvsroot/jboss - <br>password is blank (type enter)</p> - <p><b>Settings for developer access:</b></p> - <p>You have to use SSH:<br> - export CVS_RSH=ssh </p> - <p>CVSROOT is <br> - :ext:<sourceforge ID>@cvs.jboss.sourceforge.net:/cvsroot/jboss</p> - <p>For further explanations see <a href="http://sourceforge.net/cvs/?group_id=22866";>instructions</a> at sourceforge</p> - - <p class="head">MODULES - <p class="text">The following modules are available for browsing:</p> - <ul> - <li><b>jboss</b>: the main jboss tree - <li><b>jbosssx</b>: the default security implementation - <li><b>contrib</b>: 3rd party contribution to jboss - <li><b>jbosstest</b>: the testsuite for jboss - <li><b>zoap</b>: an alternative SOAP based invocation - <li><b>ejx</b>: the gui front end of jboss - <li><b>jnp</b>: the JNDI implementation - <li><b>zola</b>: the application model - <li><b>jbossmq</b>: the JMS implementation - <li><b>jbosscx</b>: the JCA implementation - <li><b>jbosspool</b>: generic object pool. A fork from Aaron Mulder's Minerva - <li><b>jboss-j2ee</b>: J2EE core classes - <li><b>manual</b>: JBoss manual - </ul> - - <p class="head">More information on Build and Source - <p class="text">What is Ant?Ant is a Java based build tool. In theory it is kind of like make without makes wrinkles. - <p class="text">Why? Why another build tool when there is already make, gnumake, nmake, jam, and others? Because, they are limited to the OS, or at least the OS type such as Unix, that you are working on. Makefiles are inherently evil as well. - <p class="text">Ant is different. Instead a model where it is extended with shell based commands, it is extended using Java classes. Instead of writing shell commands, the configuration files are XML based calling out a target tree where various tasks get executed. Each task is run by an object which implements a particular Task interface. Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}` but it gives you the ability to be cross platform. To work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an exec rule that allows different commands to be executed based on the OS that it is executing on. - <p><a class="link" href="http://jakarta.apache.org/cvsweb/index.cgi/jakarta-ant/docs/index.html%20";>more doc</a></p> - <p class="head">WHAT IS CVS (Concurrent Versions System) ? - <p class="text">CVS is a version control system. It is used to record the history of your source files. Bugs can creep in when software is modified, and may not be detected until a long time after the modification is made. With CVS, you can retrieve old versions to find which change caused the bug. - <p class="text">CVS can also help when a project is being worked on by multiple people, where overwriting each others changes is easy to do.CVS solves this problem by having each developer work in his/her own directory and then instructing CVS to merge the work when each developer is done. - <p class="text"><a class="link" href="http://www.csc.calpoly.edu/%7Edbutler/tutorials/winter96/cvs/";>more doc </a><br> - -<jsp:include page="navigation.jsp" flush="true" /> +<jsp:include page="head.jsp" flush="true" /> +<jsp:include page="slogan.jsp" flush="true" > + <jsp:param name="SLOGAN" value="SOURCE CODE AND CVS"/> +</jsp:include> + + + + <!-- CONTENT --> + <p class="head">JBOSS IS DEVELOPED PUBLICLY + <p class="text">JBoss is a free implementation of the J2EE interfaces from SUN. Our code is co-developed and the source is freely available. You + can either get the code in a zip format to browse it or, if you + plan on working with the source tree, you can set up a CVS environment + on your machine. + + <p class="text">We thank sourceforge.net for hosting our CVS. <A href="http://sourceforge.net";> <IMG src="http://sourceforge.net/sflogo.php?group_id=22866"; width="88" height="31" border="0" alt="SourceForge Logo"></A> + <p class="head">SOURCE CODE + <p class="text"><a class="link" href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/";><font face="Myriad Web,Arial"><b>Browse the source on-line</b></font></a> + <br>Download a daily updated <a class="link" href="/zip_archives/">snapshot of the sources</a> (ZIP archive) + + <p class="head">CVS ENVIRONMENT + <p class="text">To browse the source tree you <b>will need a CVS client</b>. If you don't have one already installed on your machine you can download <a class="link" href="http://www.jcvs.org/";>jCVS</a>, the CVS client in java. jCVS will work on any platform including Linux. However we recommend the native Linux tools or try <a class="link" href="http://www.wincvs.org";>winCVS</a> if you are based on a win32 platform. + <p><b>Settings for anonymous browsing:</b></p> + <p>CVSROOT is <br> + :pserver:[EMAIL PROTECTED]:/cvsroot/jboss + <br>password is blank (type enter)</p> + <p><b>Settings for developer access:</b></p> + <p>You have to use SSH:<br> + export CVS_RSH=ssh </p> + <p>CVSROOT is <br> + :ext:<sourceforge ID>@cvs.jboss.sourceforge.net:/cvsroot/jboss</p> + <p>For further explanations see <a href="http://sourceforge.net/cvs/?group_id=22866";>instructions</a> at sourceforge</p> + + <p class="head">MODULES + <p class="text">The following modules are available for browsing:</p> + <ul> + <li><b>jboss</b>: the main jboss tree + <li><b>jbosssx</b>: the default security implementation + <li><b>contrib</b>: 3rd party contribution to jboss + <li><b>jbosstest</b>: the testsuite for jboss + <li><b>zoap</b>: an alternative SOAP based invocation + <li><b>ejx</b>: the gui front end of jboss + <li><b>jnp</b>: the JNDI implementation + <li><b>zola</b>: the application model + <li><b>jbossmq</b>: the JMS implementation + <li><b>jbosscx</b>: the JCA implementation + <li><b>jbosspool</b>: generic object pool. A fork from Aaron Mulder's Minerva + <li><b>jboss-j2ee</b>: J2EE core classes + <li><b>manual</b>: JBoss manual + </ul> + + <p class="head">CVS Administration Polcies + <p class="text">For our policies on CVS versioning and branching see: <a href="CVSAdmin.html">CVS Admin</a>. + + <p class="head">More information on Build and Source + <p class="text">What is Ant?Ant is a Java based build tool. In theory it is kind of like make without makes wrinkles. + <p class="text">Why? Why another build tool when there is already make, gnumake, nmake, jam, and others? Because, they are limited to the OS, or at least the OS type such as Unix, that you are working on. Makefiles are inherently evil as well. + <p class="text">Ant is different. Instead a model where it is extended with shell based commands, it is extended using Java classes. Instead of writing shell commands, the configuration files are XML based calling out a target tree where various tasks get executed. Each task is run by an object which implements a particular Task interface. Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}` but it gives you the ability to be cross platform. To work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an exec rule that allows different commands to be executed based on the OS that it is executing on. + <p><a class="link" href="http://jakarta.apache.org/cvsweb/index.cgi/jakarta-ant/docs/index.html%20";>more doc</a></p> + <p class="head">WHAT IS CVS (Concurrent Versions System) ? + <p class="text">CVS is a version control system. It is used to record the history of your source files. Bugs can creep in when software is modified, and may not be detected until a long time after the modification is made. With CVS, you can retrieve old versions to find which change caused the bug. + <p class="text">CVS can also help when a project is being worked on by multiple people, where overwriting each others changes is easy to do.CVS solves this problem by having each developer work in his/her own directory and then instructing CVS to merge the work when each developer is done. + <p class="text"><a class="link" href="http://www.csc.calpoly.edu/%7Edbutler/tutorials/winter96/cvs/";>more doc </a><br> + +<jsp:include page="navigation.jsp" flush="true" /> 1.1 newsite/CVSAdmin.html Index: CVSAdmin.html =================================================================== <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>JBoss CVS Administration Policy</title> </head> <body> <h1>Introduction</h1> <p> This document describes the JBoss CVS administration policies for managing the sourceforge cvs repository. Comments or questions regarding these polcies should be directed to the <a href="mailto:[EMAIL PROTECTED]";>jboss-development mailing list</a> </p> <h1>Creating and Managing Release Branches</h1> The CVS branching and release management proceedures are outlined in this section. All development of new features occurs on the main trunk. Releases are done on branches off of the main trunk. <h2>Release Numbering</h2> Releases are tracked using CVS tags that have the following forms: <ul> <li>Final Binary Releases: JBoss_<major>.<even_minor>.<patch></li> <li>Beta Binary Releases: Rel_<major>.<even_minor>.<patch>.<build></li> <li>Development Binary Releases(optional): JBoss_<major>.<odd_minor>.<patch></li> <li>Alpha Development Builds(optional): Rel_<major>.<odd_minor>.<patch>.<build></li> </ul> <p>A final binary release is a tested and approved release of the JBoss server. The major and minor version numbers are fixed for a given branch. The minor version number is always even on a release branch. Example final release tags are: JBoss_2_2_0, JBoss_2_2_1, JBoss_2_4_13, JBoss_3_0_0 </p> <p> A beta binary release is a candidate final release that is being made available for testing. The major and minor version numbers are fixed for a given branch. The patch number is one greater than the current final binary. The build number indicates the number of patches that have been incorporated into the candidate release. For example, if the latest final release is JBoss_2_2_0, then next beta binary release patch number will be 1 and build numbers will start at 1. A build number of 0 is used to tag the previous final release code. So, if JBoss_2_2_0 were the latest final release, and three fixes were incorported into the 2.2 branch, there would be beta binary release tags of Rel_2_2_1_0, Rel_2_2_1_1 Rel_2_2_1_2, Rel_2_2_1_3. The idea is that beta binary releases are building to the next final binary release, in this case JBoss_2_2_1. </p> <p>A development binary release is an alpha release of the JBoss server. It is a snapshot of the functionallity in the main trunk at some point in time. The major version number is >= the latest final binary release. The minor version number is 1 greater than the latest final binary release minor version number. This means that minor versions of development binaries will always be odd. Example development binary releases are: JBoss_2_3_0, JBoss_2_3_1, JBoss_2_5_13, JBoss_3_1_0 </p> <p> A alpha development build is a patch beyond a development binary release. The patch number is one greater than the current development binary. The build number indicates the number of patches that have been incorporated into the candidate build. For example, if the latest development build is JBoss_2_3_0, then next alpha build patch number will be 1 and build numbers will start at 1. A build number of 0 is used to tag the previous devlopment build code. So, if JBoss_2_3_0 were the latest development build, and three fixes were incorported into the main trunk, there would be alpha release tags of Rel_2_3_1_0, Rel_2_3_1_1 Rel_2_3_1_2, Rel_2_3_1_3. The idea is that alpha builds are leading to the next development build, in this case JBoss_2_3_1. </p> <h2>Example Release Scenarios</h2> Consider events 1-12 in blue on the following figure: <img src="pictures/cvs_structure.png" width="700" height="550" border="0" title="CVS Branch Structure" alt="CVS Structure"> <ol start="0"> <li> Prior to event 1, the latest alpha development build is Rel_2_1_0_57. At this point it is decided to create a new binary release. <li> Event 1 is the creation of a 2.2 branch. It is labeled with a branch tag of Branch_2_2. This fixes the major version to 2 and the minor version to 2 for all tags on this branch. <li> Event 2 is the creation of a Rel_2_2_0_0 beta release tag in the branch. It serves as an alias to the state of the main branch at the time the 2.2 branch was created. <li> Event 3 is the creation of a Rel_2_3_0_0 alpha release tag on the main trunk. It it is also an alias to the state of the main branch at the time of the 2.2 branch creation. <li> Event 4 is the integration of the first patch/change into the 2.2 branch. After the code is commited the Rel_2_2_0_1 tag is applied. <li> Event 5 is the release of the initial 2.2 branch binary. The release is tagged as JBoss_2_2_0 as well as Rel_2_2_1_0 to start the next beta series. <li> Event 6 is the integration of the first patch/change after the 2.2.0 binary release. After the code is commited the Rel_2_2_1_1 tag is applied. <li> Event 7 is the release of the second 2.2 branch binary. The release is tagged as JBoss_2_2_1 as well as Rel_2_2_2_0 to start the next beta series. <li> Event 8 is the creation of a new binary release branch. After some period of development on the 2.3 releases(Rel_2_3_0_0 to Rel_2_3_1_37), it is decided to release a final binary incorporating the main trunk functionality. The new 2.4 branch is labeled with a branch tag of Branch_2_4. This fixes the major version to 2 and the minor version to 4 for all tags on this branch. <li> Event 9 is the creation of a Rel_2_4_0_0 beta release tag in the branch. It serves as an alias to the state of the main branch at the time the 2.4 branch was created. <li> Event 10 is the creation of a Rel_2_5_0_0 alpha release tag on the main trunk. It it is also an alias to the state of the main branch at the time of the 2.4 branch creation. <li> Event 11 is the integration of the first patch/change into the 2.4 branch. After the code is commited the Rel_2_4_0_1 tag is applied. <li> Event 12 is the release of the initial 2.4 branch binary. The release is tagged as JBoss_2_4_0 as well as Rel_2_4_1_0 to start the next beta series. </ol> <h1>CVS Task HowTo</h1> <h2>Checking code into the main trunk</h2> New features and bug fixes on unreleased code should go into the main trunk which is the latest development branch. The steps for doing this are: <ol> <li>Checkout the target module in which the changes are to be made. For example to commit changes to the jboss module do: <pre>cvs co jboss</pre> <li>Make your chages to the source in the jboss working directory created by the previous check out. <li>Commit your changes. Do this by executing the following command in the directory you made the changes in, or any common parent directory: <pre>cvs commit -m "Your commit msg"</pre> You don't have to specify the commit msg on the commit command line. If you don't you will be prompted for the commit msg. Note that this will apply the same commit msg to all files you have changed. If you want specific commit msgs for each file then you can perform a seperate commit on each file. <li>(optional) Tag the code with the next alpha build tag. For example, to tag the jboss source tree with a Rel_2_3_1_3 tag, do: <pre>cvs tag Rel_2_3_1_3</pre> from within the jboss/src working directory. </ol> <h2>Creating a new binary release branch</h2> <ol> <li> Perform a clean check out of the jboss main branch without any tags to select the latest code: <pre> cvs co jboss </pre> <li> Create the new branch giving it a branch tag of Branch_<major>_<minor>. For example, to create a 2.2 branch, perform the following within the working directory created by the previous check out: <pre> cvs tag -b Branch_2_2 </pre> <li> Create a working directory for the new branch by checking it out using the Branch_2_2 tag: <pre> cvs co -r Branch_2_2 </pre> <li> Label the branch working directory with the initial beta release tag of Rel_<major>_<minor>_0_0. For the Branch_2_2 case this would be done by executing the following in the working directory created by the previous check out: <pre> cvs tag Rel_2_2_0_0 </pre> </ol> <h2>Checking in a patch on a release branch</h2> When you have changes that need to go into the codebase of a release branch, you need to check out that branch and make the changes. So for example, if you need to add a patch the the 2.2 branch of the example cvs structure above, you need to first check out the 2.2 branch using the Branch_2_2 tag. <li>Checkout the module using the branch tag you want to work on. To checkout the 2.2 branch of the jboss module do: <pre>cvs co -r Branch_2_2 jboss</pre> This will create a jboss working directory with a sticky tag that associates the source code with the 2.2 branch. If you look at the jboss/src/main/org/jboss/Main.java file in the jboss working directory that results from the previous command using the cvs status command you will see something like: <pre> bash-2.04$ cd jboss/src/main/org/jboss/ bash-2.04$ cvs status Main.java =================================================================== File: no file Main.java Status: Needs Checkout Working revision: 1.30.2.6 Repository revision: 1.30.2.6 /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v Sticky Tag: Branch_2_2 (branch: 1.30.2) Sticky Date: (none) Sticky Options: (none) </pre> This shows that the "Sticky Tag:" is set to the Branch_2_2 tag as we requested. <li>Make your chages to the source in the jboss working directory created by the previous check out. <li>Commit your changes. Do this by executing the following command in the directory you made the changes in, or any common parent directory: <pre>cvs commit -m "Your commit msg"</pre> You don't have to specify the commit msg on the commit command line. If you don't you will be prompted for the commit msg. Note that this will apply the same commit msg to all files you have changed. If you want specific commit msgs for each file then you can perform a seperate commit on each file. <li>(Required) Tag the branch with the next beta binary release tag by incrementing the build number of the latest tag. To determine what build number to use, look at all of the tags for a file using the cvs status command with the -v option. For example, looking at jboss/src/main/org/jboss/Main.java again: <pre> bash-2.04$ cvs status -v Main.java =================================================================== File: no file Main.java Status: Needs Checkout Working revision: 1.30.2.6 Repository revision: 1.30.2.6 /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v Sticky Tag: Branch_2_2 (branch: 1.30.2) Sticky Date: (none) Sticky Options: (none) Existing Tags: Rel_2_3_1_0 (revision: 1.34) Rel_2_2_2_0 (revision: 1.30.2.6) JBoss_2_2_2 (revision: 1.30.2.6) JBoss_2_2_1 (revision: 1.30.2.3) Rel_2_2_1_0 (revision: 1.30.2.3) </pre> The Rel_2_2_2_0 tag is the latest tag on the 2.2 branch and indicates that no patches have been made since the JBoss_2_2_2 release. So to tag the changes you have made you need to use Rel_2_2_2_1. Do this using: <pre>cvs tag Rel_2_2_2_1</pre> from the top of the jboss working directory. <li>(Required) Merge the changes to the main trunk if they are missing. You need to validate that the changes you have made to the release branch are not already in the main trunk and merge the changes if they are. <li>(Required, if merge was done) Check out the latest trunk code: <pre>cvs co jboss</pre> <li>(Required, if merge was done) Tag the main trunk with the next alpha build tag. Assuming the this is Rel_2_3_1_5, you would do: <pre>cvs tag Rel_2_3_1_5</pre> from within the jboss working directory you just checked out. </ul> </body> </html> _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
