===== Request for Comments: Move PHP's source code and docs to something that isn't CVS =====

  * **Version:** 0.0.1
  * **Date:** 2008-03-29
  * **Author:** Gwynne Raskind
  * **Status:** Accepted
  * **Progress:** Roughly 90% implemented, see [[http://svn.php.net/]]
  * **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.

==== Purpose ====

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 ===
Some comments on SVN, partially from [[http://wiki.pooteeweet.org/PHPSVN/]] and edited for clarity:

Reasons for SVN:
  - Client-side diffs (faster, offline, less server strain)
  - 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
  - Directories, renames, etc. are all versioned.
  - Ability to use SVK (star merges, and more)
  - 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:
  - <del>Larger checkout size</del> - An inevitability anyway as the code base grows
  - <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
  - <del>is svn as flexible with encoding as CVS?</del> - SVN is in fact considerably moreso
  - <del>SVN doesn't have real tags</del>

On the subject of SVN tags, php [AT] adamashley [DOT] name says:
>> SVN doesn't have real tags
> thank god. how many times have you created a tag and need to come back and turn it into a branch? the under lying system should place limitations upon how you use it, those limitations should only be agreed upon and implemented by the people using the system.

=== Git ===

//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. 
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 ====

Could we summarize what is wrong with the current system, to have some criterias to be able to choose a suitable system?

For example:
  * Development Systems to be supported: Linux?, Windows?, Solaris?,...
  * Support for advanced karma management
  * ...




==== Further Discussion And Reading ====
[[http://news.php.net/svn.migration]]

[[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://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.infoq.com/articles/dvcs-guide]] DVCS Overview with comparison of Git, Hg, and Bzr

[[http://bazaar-vcs.org/BzrVsGit]] Bazaar vs GIT (from the Bazaar Point of View)

[[http://tomayko.com/writings/the-thing-about-git]] Shows how git solves the "The Tangled Working Copy Problem", with nice examples and a discussion/reference to other VCSes as well

[[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://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