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 Subversion, Git, Mercurial and 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:
Larger checkout size - An inevitability anyway as the code base grows
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
$Id$ equivalent does not generate consequtive numbering per file
is svn as flexible with encoding as CVS? - SVN is in fact considerably moreso
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.
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 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
Cool. Can you now prove that CVS, SVN, Bazaar and, in particular, Mercurial are significantly slower?
Reasons against GIT:
-
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