Changes between Version 24 and Version 25 of WorkingConventions/Git


Ignore:
Timestamp:
Nov 16, 2012 1:27:18 AM (17 months ago)
Author:
joeyadams
Comment:

Fix some spelling and capitalization errors

Legend:

Unmodified
Added
Removed
Modified
  • WorkingConventions/Git

    v24 v25  
    1111 
    1212 * Separate changes that affect functionality from those that just affect 
    13    code layout, indendation, whitespace, filenames etc.  This means that 
     13   code layout, indentation, whitespace, filenames etc.  This means that 
    1414   when looking at patches later, we don't have to wade through loads of 
    1515   non-functional changes to get to the important parts of the patch.    
     
    6363All changes to GHC and the libraries need to be [wiki:TestingPatches validated] before they can be pushed to the main repositories.  Validation can take a while - 30 minutes on a 4-core machine is typical - so ideally you want to be validating changes while you are working in a separate tree.  In fact, there are other compelling reasons to have two trees in your development workflow, one for working in and one for validation: 
    6464 
    65  * validation uses build settings that are different to the ones you would normally use while developing: it adds more libraries (DPH), builds extra ways (dynamic libraries), and builds all the documentation, so you don't want to use the same build for validation and ordinary development.  In the development tree we use build settings optimised for development: `-O0 -DDEBUG` for the compiler, minimal libraries and ways so that rebuilding is fast. 
     65 * Validation uses build settings that are different to the ones you would normally use while developing: it adds more libraries (DPH), builds extra ways (dynamic libraries), and builds all the documentation, so you don't want to use the same build for validation and ordinary development.  In the development tree we use build settings optimised for development: `-O0 -DDEBUG` for the compiler, minimal libraries and ways so that rebuilding is fast. 
    6666 
    67  * Having two trees elimiantes a common source of breakage in the main repository: with one tree it is easy to add new files but forget to commit them.  Your tests will work, but the build will be broken for others.  If you have to pull your changes into a separate tree for testing, you'll notice the missing files before you push. 
     67 * Having two trees eliminates a common source of breakage in the main repository: with one tree it is easy to add new files but forget to commit them.  Your tests will work, but the build will be broken for others.  If you have to pull your changes into a separate tree for testing, you'll notice the missing files before you push. 
    6868 
    6969The typical workflow is to work in the development tree, pull into the validate tree, validate, and then push from the validate tree.  But what if validate fails?  There are two options: