Login | Register
My pages Projects Community openCollabNet

Discussions > commits > svn commit: r7 - trunk/www

sin
Discussion topic

Back to topic list

svn commit: r7 - trunk/www

Reply

Author chorns
Full name Casper Hornstrup
Date 2005-08-01 05:46:25 PDT
Message Author: chorns
Date: Mon Aug 1 05:46:25 2005
New Revision: 7

Modified:
   trunk/www/Sin - Continuous Integration Rethought.html
Log:
Try to fix some layout problems

Modified: trunk/www/Sin - Continuous Integration Rethought.html
Url: http://sin.tigris.or​g/source/browse/sin/​trunk/www/Sin%20-%20​Continuous%20Integra​tion%20Rethought.htm​l?view=diff&rev=​7&p1=trunk/www/S​in%20-%20Continuous%​20Integration%20Reth​ought.html&r1=6​&p2=trunk/www/Sin​%20-%20Continuous%20​Integration%20Rethou​ght.html&r2=7
====================​====================​====================​==================
--- trunk/www/Sin - Continuous Integration Rethought.html (original)
+++ trunk/www/Sin - Continuous Integration Rethought.html Mon Aug 1 05:46:25 2005
@@ -9,7 +9,7 @@
   <link rel="stylesheet" type="text/css" href="http://www.tigris.or​g/branding/css/print​.css" media="print" />
 <script src="http://www.tigris.or​g/branding/scripts/t​igris.js" type="text/javascript">
 </script>
- <title>Sin: Continuous Integration Rethought</title>
+ <title>Continuous Integration Rethought</title>
 </head>
 <body>
 
@@ -19,7 +19,9 @@
 <table cellspacing="0" cellpadding="0" width="100%">
 <tr>
     <td width="100%" align="center" style="text-align:center">
- <font size="6"><b>Sin: Continuous Integration Rethought</b>​</font>
+ <br>
+ <font size="5"><b>Sin: Continuous Integration Rethought</b>​</font>
+ <br>
     </td>
 </tr>
 <tr>
@@ -37,7 +39,7 @@
 <h2>Continuous Integration</h2>
 <p>
 We have learned that <a href="http://www.martinfow​ler.com/articles/con​tinuousIntegration.h​tml">Continuous Integration</a> can help us catch bugs early. Continuous Integration is the concept of continuously building and testing software using an automated process. I'll begin by describing how most (if not all) existing Continuous Integration systems work and the problems with that approach. Then I'll explain what Sin does differently and what benefits the user get from doing it this way.</p>
-
+<br>
 <h2>The usual approach</h2>
 <p>The usual approach to Continuous Integration is like this. There is a central Version Control System repository containing the source code. There is one or more machines, known as build machines, that regularly checks out copies of the latest source code from the repository, try to build them and run tests on the resulting binaries. The output from this is published onto a website and/or is sent to the developers that has checked in new changes that are included in the build using a mailing list, Instant Messenger or other communication channel. Working and non-working versions of the source code are usually marked with green (for working versions) and red (for non-working versions) colors on the website. There can be formulated strategies for resolving these integration problems that cause non-working source code to be put into the repository. One strategy could be that the developer who checked in the change that caused the source code to not work should commit a new change that fixes the problem (or remove the bad change). A second strategy could be that the first person that discovers the problem should fix it and notify all other developers that it was fixed.</p>
 
@@ -52,7 +54,7 @@
 </ul>
 
 <p>Until the integration problem is resolved in the repository, there is a risk that other developers update their working copies, only to find their working copies to contain non-working source code. Again, developers are interrupted in their work since they now have to fix the problem themselves. Since <a href="http://www.joelonsof​tware.com/articles/f​og0000000022.html">human task switches are considered harmful</a>, these interruptions are potentially big time-consumers.</p>
-
+<br>
 <h2>How does Sin work?</h2>
 <p>Sin works a bit differently in some areas, but not in others. Sin introduces the concepts of checkin and stable branches. Usually, when you want to do parallel development, you create a branch separate from the main branch, thereby having two separate branches in the repository. Sin further subdivides each branch into a checkin and a stable branch, thereby making the total number of branches in the repository four. The layout of the repository could look like this:</p>
 <pre>
@@ -66,7 +68,7 @@
 <p>Sin can be seen as being made up of two parts, the Integration Manager and the pool of Integrators. The Integration Manger is responsible for controlling the integration process of the changes. It will notice new changes to checkin branches in the repository, ask available Integrators to validate the changes, and perform the needed merges within the repository in order to complete the integration of the changes. If a change could be verified then the change is merged from the checkin branch to the stable branch. If a change could not be verified then the change is reverted (undone) from the checkin branch. It will be almost like the developer had never committed the change (except that no information is ever lost in a version control system). If a change is reverted then the developer that committed the change is emailed information about what was wrong with with the change. The developer can then merge the change back into his working copy, fix the problem and commit it again. The Integrator will, when asked to validate a change, checkout the source code from the stable branch in the repository, apply the change that is to be integrated, validate the change, and report either success or failure back to the Integration Manager which then take an appropriate action.</p>
 
 <p>So, we have the checkin branches which may or may not contain working source code and we have the stable branches which always contain working source code. To be guaranteed that their working copies contain working source code after an update with the latest changes to the repository, the developers must create their working copies from the stable branches. When it's time to commit a change, the working copy must be switched over to the checkin branch and then the change can be committed to the checkin branch. Since the checkin branch and the stable branch don't have many differences, switching the working copy between these two branches is usually a fast operation.</p>
-
+<br>
 <h2>What are the benefits?</h2>
 <p>The benefits are many.<p>
 <ul>
@@ -76,7 +78,7 @@
 
     <li><p>Heightened developer morale. By removing the broken build experiences, developers will have higher morale. This will also result in higher productivity.</p​></li>
 </ul>
-
+<br>
 <h2>Hardware requirements vs. level of protection</h2>
 <p>For large projects, a considerable amount of hardware may be required to have an acceptable performance of the Sin system. If you have the required hardware for it, I'd say build it all for every change. Building everything for every change gives you several benefits:<p>

« Previous message in topic | 1 of 1 | Next message in topic »

Messages

Show all messages in topic

svn commit: r7 - trunk/www chorns Casper Hornstrup 2005-08-01 05:46:25 PDT
Messages per page: