• Version: 0.0.1
• Date: 2008-03-29
• Author: Gwynne Raskind
• Status: In the works
• Votes: (+0/-0)
  • Pro:
  • Contra:

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 Subversion, Git and Mercurial.

Some comments on SVN, partially from http://wiki.pooteeweet.org/PHPSVN/ and edited for clarity:

Reasons for SVN:

1. Client-side diffs (faster, offline, less server strain)
2. Serving via apache2 makes all sorts of things possible (better karma management)
3. SVN correctly handles binary types and all newline styles
4. Directories, renames, etc. are all versioned.
5. Ability to use SVK (star merges, and more)
6. Ability to do external includes (e.g. pear stuff into pecl/pearweb)

Reasons against SVN:

1. Larger checkout size - An inevitability anyway as the code base grows
2. SVN tools not available in all distros by default - This is no longer true in modern systems, and it is easily installed on those which don't come with it
3. $Id$ equivalent does not generate consequtive numbering per file
4. Developers will need to learn to do some things differently - SVN's interface is very similar to CVS's.
5. is svn as flexible with encoding as CVS? - SVN is in fact considerably moreso
6. SVN doesn't have real tags

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.

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.

Reasons for GIT:

1. Local working branches that are invisible to other. Every developer can start his own branch at home doing feature or topic based branches
2. Merge tracking and cherry-picking
3. Cryptographical secure, means that if the repository is corrupted GIT will notice that as every content and commit is backed by a SHA1
4. Small repository size: Test impots 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
5. Ablility to completly remove files/folders and it's history from the repository (e.g. due to copyright reasons)
6. 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.
7. Extreme fast (On Mac OSX 10.5 with 2×2.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

Reasons against GIT:

1. 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
2. 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
3. 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.
4. 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?

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

http://doc.php.net/php/rfc/rfc-proposal-show.php?id=8

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