rfc:phpvcs
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
rfc:phpvcs [2008/05/27 23:13] – thezapper | rfc:phpvcs [2009/05/17 13:32] – updated status to "yes on svn", linked to svn.migration list, added progress category philip | ||
---|---|---|---|
Line 4: | Line 4: | ||
* **Date:** 2008-03-29 | * **Date:** 2008-03-29 | ||
* **Author:** Gwynne Raskind | * **Author:** Gwynne Raskind | ||
- | * **Status: | + | * **Status: |
- | * **Votes:** (+0/-0) | + | * **Progress:** Roughly 90% implemented, |
- | * **Pro:** | + | * **Votes:** While most people prefer a move to Git/Github, a more unanimous desire is required before such a large shift. We're sticking with the status quo and moving to SVN. A git bridge will exist. |
- | * **Contra:** | + | |
==== Purpose ==== | ==== Purpose ==== | ||
- | The idea is to get PHP away from CVS, which while a venerable and respected | + | The idea is to get PHP away from venerable |
=== Subversion === | === Subversion === | ||
Line 19: | Line 18: | ||
- Client-side diffs (faster, offline, less server strain) | - Client-side diffs (faster, offline, less server strain) | ||
- Serving via apache2 makes all sorts of things possible (better karma management) | - Serving via apache2 makes all sorts of things possible (better karma management) | ||
+ | - Native windows support (able to use transparent authentication with domain proxies) | ||
- SVN correctly handles binary types and all newline styles | - SVN correctly handles binary types and all newline styles | ||
- Directories, | - Directories, | ||
- Ability to use SVK (star merges, and more) | - Ability to use SVK (star merges, and more) | ||
- Ability to do external includes (e.g. pear stuff into pecl/ | - Ability to do external includes (e.g. pear stuff into pecl/ | ||
+ | - SVN's interface is very similar to CVS's | ||
+ | - Partial checkouts | ||
+ | - Linear project history can be converted to provide mirrors to other VCS | ||
Reasons against SVN: | Reasons against SVN: | ||
Line 28: | Line 31: | ||
- < | - < | ||
- $Id$ equivalent does not generate consequtive numbering per file | - $Id$ equivalent does not generate consequtive numbering per file | ||
- | - < | ||
- < | - < | ||
- < | - < | ||
Line 39: | Line 41: | ||
//Insert stuff here// | //Insert stuff here// | ||
- | Question: How official is the win32 support of git at the moment? [[http:// | + | Question: How official is the win32 support of git at the moment? [[http:// |
+ | Answer: with GIT 1.6.0 the MinGW Project is merged into GIT, which means that git should run nicely under Windows. | ||
+ | Question2: MinGW is a separate project from GIT. Even if GIT compiles successfully, | ||
+ | |||
+ | Reasons for GIT: | ||
+ | - Local working branches that are invisible to other. Every developer can start his own branch at home doing feature or topic based branches \\ > that hardly can be an advantage, because it hardens code review. It is better to say that GIT allows to develop project with incremental commits in in offline. | ||
+ | - Merge tracking and cherry-picking \\ > Is there a scenario to study these features? | ||
+ | - Cryptographical secure, means that if the repository is corrupted GIT will notice that as every content and commit is backed by a SHA1 \\ > Why GIT repositories are getting corrupted? | ||
+ | - Small repository size: Test imports of the complete history of PHP (php-src + ZendEngine2) from 1999 until now, with the complete history takes 135M of repository data. This was done using parsecvs to import the repository and than doing a git repack --depth 100 --window=250 | ||
+ | - Ablility to completly remove files/ | ||
+ | - No karma management required: As GIT is decentralized every developer can have it's own repository. Access to official public repositories (e.g. ZendEngine2.git) can be done using ssh-keys. Depending on the infrastructure that is used, GIT can be used compeltly centralized or just a small set of team can have access to centralized official repositories and integrate patches from other developers. | ||
+ | - Extreme fast (On Mac OSX 10.5 with 2x2.1 Ghz and 2GB Ram | ||
+ | |||
+ | diff | ||
+ | $ time git --no-pager diff 5.2 5.3 ( a complete diff between 5.2 and 5.3 branches ) | ||
+ | | ||
+ | | ||
+ | | ||
+ | Checkout: Switching branches between 5.2 and 5.3 with | ||
+ | $ time git checkout 5.3 | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | > Cool. Can you now prove that CVS, SVN, Bazaar and, in particular, Mercurial are significantly slower? | ||
+ | |||
+ | Reasons against GIT: | ||
+ | - Bad windows support. \\ >> Not longer true, msysgit does a great job, and it's going to be included into the GIT mainline with the next (1.6.0) release. \\ > It is still true. http:// | ||
+ | - Few gui tools: git comes with git-gui and gitk which are TK based guis that work under all operating systems. They can help to use git but they are not a complete replacement for the command line | ||
+ | - Different from CVS and SVN: The way GIT works (especially branching) is different from the way CVS or SVN works. While this is the reasons why developers pick up GIT, it might definatly confuse people not familar with GIT. | ||
+ | - New infrastructure: | ||
+ | |||
+ | |||
+ | === Mercurial === | ||
+ | |||
+ | === Bazaar === | ||
==== Requirements ==== | ==== Requirements ==== | ||
Line 54: | Line 92: | ||
==== Further Discussion And Reading ==== | ==== Further Discussion And Reading ==== | ||
+ | [[http:// | ||
+ | |||
[[http:// | [[http:// | ||
[[http:// | [[http:// | ||
- | |||
- | [[http:// | ||
- | |||
- | [[http:// | ||
[[http:// | [[http:// | ||
Line 72: | Line 108: | ||
[[http:// | [[http:// | ||
- | [[http:// | + | [[http:// |
[[http:// | [[http:// | ||
+ | |||
+ | [[http:// |
rfc/phpvcs.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1