Version 15 (modified by dukeleto, 12 years ago)


Objections to using Git as a VCS, per discussion at .

1. Objection: Integration with trac.

2. Objection: Demonstrate that git actually is better at resolving the merging conflicts we hit in real usage.

  • Answer 2.1: I know that specific examples would be great here, but does anyone actually doubt that merging is less painful in git?

3. Objection: Source code browsing tools. (including revision browsing)

4. Objection: Down-time and retraining time for developers.

  • Answer 4.1: Migration will take time -- no answer to that.
  • Answer 4.2: Developers can retrain with git-svn prior to migration. If anything, Using Git alone is *easier* than with git-svn. Developers can also fork the mirror of Parrot on github and practice their git workflow.
  • Answer 4.3: Git supports a workflow very much like the existing SVN workflow. It's not the ideal Git workflow, but it's similar enough that retraining will be short. (See also GitCookbook-Pm.)
  • Question 4.4: How many existing active committers and developers might need retraining? I suspect the number is small.

5. Objection: Safety of the core source (limiting the damage possible accidentally or by new committers)

  • Claim 5.1: (with git it's possible to make changes that destroy the history of the repository)
    • 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).
  • 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.
  • 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.
  • 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 were to be hit by a meteor, we would be in a bad way. Our code is safer in git.

6. Objection: Upstream projects depend on getting Parrot from svn.

  • 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.
    • 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 have a dependency on the master Parrot VCS do so at their own risk.
  • Answer 6.2: It is also reasonably trivial to have a subversion mirror of the Parrot git master branch.