Changes between Version 9 and Version 10 of GitObjections

Show
Ignore:
Timestamp:
09/18/09 02:41:36 (12 years ago)
Author:
pmichaud
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • GitObjections

    v9 v10  
    1717 
    18185. Objection: Safety of the core source (limiting the damage possible accidentally or by new committers) 
    19    * Claim: (with git it's possible to make changes that destroy the history of the repository) 
    20    * Answer 5.1: Have a server side post-commit hook that disallows non-fast-forward updates. That negates any possibility of a newbie messing up the master Parrot git repo. 
    21    * Answer 5.2: Also, the history is not destroyed, just altered. The history is still there and can easily be fixed from another Parrot git repo. 
    22    * Answer 5.3: Every single git work tree of Parrot is a backup of the entire source code history. Currently, if the svn repo on parrot.org were to be hit by a meteor, we would be in a bad way. Our code is safer in git.  
     19   * Claim 5.1: (with git it's possible to make changes that destroy the history of the repository) 
     20     * Counter-claim 5.1.1:  This seems very unlikely to happen, and detecting/mitigating a problem is not at all difficult (see Answers 5.2 through 5.4 below). 
     21   * Answer 5.2: Have a server side post-commit hook that disallows non-fast-forward updates. That negates any possibility of a newbie messing up the master Parrot git repo. 
     22   * Answer 5.3: Also, the history is not destroyed, just altered. The history is still there and can easily be fixed from another Parrot git repo. 
     23   * Answer 5.4: Every single git work tree of Parrot is a backup of the entire source code history. Currently, if the svn repo on parrot.org were to be hit by a meteor, we would be in a bad way. Our code is safer in git.  
    2324 
    24256. Objection: Upstream projects depend on getting Parrot from svn. 
    25    * Answer 6.1: Ensure that those projects are given sufficient advance notice of any VCS switch.  This includes HLLs and derivative projects such as mod_parrot.  A list of such projects should be maintained. 
     26   * Claim 6.1: Ensure that those projects are given sufficient advance notice of any VCS switch.  This includes HLLs and derivative projects such as mod_parrot.  A list of such projects should be maintained. 
     27     * Counter-claim 6.1.1: According to Parrot policies, HLLs and other projects should not be dependent on the VCS but should restrict their work to released versions of Parrot.  Projects that choose to download directly from the master Parrot repo do so at their own risk. 
    2628   * Answer 6.2: It is also reasonably trivial to have a subversion mirror of the Parrot git master branch.