Version 7 (modified by dukeleto, 12 years ago)

--

Objections to using Git as a VCS, per discussion at  http://irclog.perlgeek.de/parrot/2009-09-17#i_1510436 .

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)

  • Answer 3.1: gitweb - has more fancy features, like avatars and such
  • Answer 3.2: cgit - faster/less resource-heavy, but written in C

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.
  • 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.

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

  • Claim: (with git it's possible to make changes that destroy the history of the repository)
  • 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.
  • 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.

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

  • 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.
  • Answer 6.2: It is also reasonably trivial to have a subversion mirror of the Parrot git master branch.