rfc:phpvcs

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:phpvcs [2008/05/27 23:13] thezapperrfc:phpvcs [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 4: Line 4:
   * **Date:** 2008-03-29   * **Date:** 2008-03-29
   * **Author:** Gwynne Raskind   * **Author:** Gwynne Raskind
-  * **Status:** In the works +  * **Status:** Accepted 
-  * **Votes:** (+0/-0) +  * **Progress:** Roughly 90% implemented, see [[http://svn.php.net/]] 
-    * **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 version control system, is just too old to serve our needs any longer. Several different newer systems have been proposed, notably [[http://subversion.tigris.org/|Subversion]], [[http://git.or.cz/|Git]] and [[http://www.selenic.com/mercurial/wiki/|Mercurial]].+The idea is to get PHP away from venerable CVS version control system, which is just too old to serve our needs any longer. Several different newer systems have been proposed, notably [[http://subversion.tigris.org/|Subversion]], [[http://git.or.cz/|Git]][[http://www.selenic.com/mercurial/wiki/|Mercurial]] and [[http://bazaar-vcs.org/|Bazaar]]
  
 === 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, renames, etc. are all versioned.   - Directories, renames, etc. are all versioned.
   - 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/pearweb)   - Ability to do external includes (e.g. pear stuff into pecl/pearweb)
 +  - 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:
   - <del>SVN tools not available in all distros by default</del> - This is no longer true in modern systems, and it is easily installed on those which don't come with it   - <del>SVN tools not available in all distros by default</del> - This is no longer true in modern systems, and it is easily installed on those which don't come with it
   - $Id$ equivalent does not generate consequtive numbering per file   - $Id$ equivalent does not generate consequtive numbering per file
-  - <del>Developers will need to learn to do some things differently</del> - SVN's interface is very similar to CVS's. 
   - <del>is svn as flexible with encoding as CVS?</del> - SVN is in fact considerably moreso   - <del>is svn as flexible with encoding as CVS?</del> - SVN is in fact considerably moreso
   - <del>SVN doesn't have real tags</del>   - <del>SVN doesn't have real tags</del>
Line 39: Line 41:
  
 //Insert stuff here// //Insert stuff here//
-Question: How official is the win32 support of git at the moment? [[http://code.google.com/p/msysgit/]] says it is currently merged into official distribution.+Question: How official is the win32 support of git at the moment? [[http://code.google.com/p/msysgit/]] says it is currently merged into official distribution.  
 +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, what about proxy support - is it able to detect them and authenticate in domain environment? 
 + 
 +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  \\ > Why should I care about the size of repository? Does that mean that every working copy is a complete repository copy? I.e. is it possible to do partial checkouts? 
 +  - Ablility to completly remove files/folders and it's history from the repository (e.g. due to copyright reasons)   \\ > Every VCS supports this via admin commands. If any user can exploit this ability then it is definitely a reason not to use this VCS. 
 +  - 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 ) 
 +     real        0m13.283s 
 +     user        0m3.390s 
 +     sys         0m2.125s 
 +    Checkout: Switching branches between 5.2 and 5.3 with 
 +     $ time git checkout 5.3 
 +     real        0m5.774s 
 +     user        0m0.923s 
 +     sys         0m1.358s 
 + 
 +> 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://code.google.com/p/msysgit/issues/list 
 +  - 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: Due to it's decentralized nature, switching to GIT will require a discussion how to setup a infrastructure: Is GIT used completly centralized, or are there official php-src, Zend repositories were just a few people can commit who then integerate patches from other people? 
 + 
 + 
 +=== Mercurial === 
 + 
 +=== Bazaar === 
  
 ==== Requirements ==== ==== Requirements ====
Line 54: Line 92:
  
 ==== Further Discussion And Reading ==== ==== Further Discussion And Reading ====
 +[[http://news.php.net/svn.migration]]
 +
 [[http://doc.php.net/php/rfc/rfc-proposal-show.php?id=8]] [[http://doc.php.net/php/rfc/rfc-proposal-show.php?id=8]]
  
 [[http://marc.info/?t=118036801200001&r=1&w=2|Better Changeset Tracking]] [[http://marc.info/?t=118036801200001&r=1&w=2|Better Changeset Tracking]]
- 
-[[http://del.icio.us/sebastian_bergmann/scm]] 
- 
-[[http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/]] 
  
 [[http://www.javaworld.com/javaworld/jw-09-2007/jw-09-versioncontrol.html]] Maybe not the best article but a starting point, compares CVS, Subversion, Bazaar, Mercurial [[http://www.javaworld.com/javaworld/jw-09-2007/jw-09-versioncontrol.html]] Maybe not the best article but a starting point, compares CVS, Subversion, Bazaar, Mercurial
Line 72: Line 108:
 [[http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html]] Why mozilla chose mercurial [[http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html]] Why mozilla chose mercurial
  
-[[http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/7532d66890f63768]] Mozilla people discussing mercurial and git and others+[[http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/7532d66890f63768|Mozilla people discussing mercurial and git and others]]
  
 [[http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html]] Another Mercurial vs. GIT [[http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html]] Another Mercurial vs. GIT
 +
 +[[http://www.python.org/dev/peps/pep-0347/|Migrating the Python CVS to Subversion]] Rationale and procedure
rfc/phpvcs.1211930029.txt.gz · Last modified: 2017/09/22 13:28 (external edit)