HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/plain; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 03:49:19 GMT Content-length: 2931 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) 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. * Answer 1.1: http://trac-hacks.org/wiki/GitPlugin 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. Example of an older (git 1.5.x) gitweb instance: http://leto.net/gitweb/ * 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. (See also [wiki: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 parrot.org 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 download directly from the master Parrot repo 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. t;strong>component</str