rfc:dvcs

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:dvcs [2011/08/07 19:38] dsprfc:dvcs [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Request for Comments: Choosing a distributed version control system for PHP ====== ====== Request for Comments: Choosing a distributed version control system for PHP ======
-  * Version: 0.1+  * Version: 1.0
   * Date: 2011-07-30   * Date: 2011-07-30
   * Author: David Soria Parra <dsp at php dot net>   * Author: David Soria Parra <dsp at php dot net>
-  * Status: Draft+  * Status: Accepted with Option Git [[rfc:dvcs:vote|Voting Results]] (Voting ended Sep 7, 2011 12:00 UTC)
   * First Published at: http://wiki.php.net/rfc/dvcs   * First Published at: http://wiki.php.net/rfc/dvcs
  
Line 9: Line 9:
  
 PHP uses Subversion (SVN) as its version control system of choice at the PHP uses Subversion (SVN) as its version control system of choice at the
-moment.  These has a few drawbacks. A decentralized version control system +moment. This has a few drawbacks. A decentralized version control system 
-can solve some of these drawbacks. This RFC aims to provide information to +can solve some of these drawbacks. This RFC aims to provide information helpful 
-choose one of the proposed decentralized version control systems (DVCS).+in choosing one of the proposed decentralized version control systems (DVCS).
  
 ===== Current Situation ===== ===== Current Situation =====
-Subversion is used to host the main PHP repository and sub projects such as +Subversion is used to host the main PHP repository, as well as several 
-PEAR and PECL. Access is granted through an implemented Karma System (KARMA)+sub-projects such as PEAR and PECL. Access to the repository is controlled 
-Using Subversion has drawbacks: +through the Karma system, which uses a custom implementation. 
-  * requires network access+ 
 +Using Subversion has several drawbacks: 
 +  * requires network access (and SVN's network access over HTTP is very slow)
   * slow log/annotate commands   * slow log/annotate commands
   * large checkout sizes   * large checkout sizes
   * single point of failure   * single point of failure
   * painful merging   * painful merging
-  * no implizit consistency checks+  * no implicit consistency checks
  
-Decentralized version control system can solve this:+Decentralized version control system can solve several issues:
   * better merging support   * better merging support
   * consistency checks using SHA1 checksums   * consistency checks using SHA1 checksums
   * local repository, no network access required to commit   * local repository, no network access required to commit
-  * network access only for push/pull +  * network access only for push/pull (and faster network operations) 
-  * no single point of failure, easy to setup multiple hostings +  * no single point of failure, easy to setup multiple hosting 
-  * advanced features such as rebase to linearize history, bisect to find regression bugs+  * advanced features such as rebase to linearise history, bisect to find regression bugs
   * "social coding platforms" enabling developers to easily submit patches.   * "social coding platforms" enabling developers to easily submit patches.
  
-Decentralized version control system have some drawbacks:+Decentralized version control systems have some drawbacks:
   * no partial checkout of subdirectories   * no partial checkout of subdirectories
   * no empty directories, .keep file needed   * no empty directories, .keep file needed
-  * no global unique incrementing rev numbers, sha1s are global unique revnums +  * no global unique incrementing rev numbers, SHA1s are global unique revnums 
-  * no svn:externals, no svn:eol-style+  * no svn:externals, no svn:eol-style (solved with extensions) 
 + 
 +===== Overview of Competitors =====
  
-===== Overview Competitors ===== 
 ==== Git ==== ==== Git ====
-Git was written by Linus Torvalds as a replacement for BitKeeper that was+Git was written by Linus Torvalds as a replacement for BitKeeper, which was
 used for Linux Kernel development until 2005. Git is used by various large used for Linux Kernel development until 2005. Git is used by various large
 Open Source Projects, including Perl, VLC and Gnome. It is considered Open Source Projects, including Perl, VLC and Gnome. It is considered
-the fastest Open Source DVCS.+the most popular and best known Open Source DVCS.
  
-Git is written in C, Shell and Perl. It runs under Linux, BSD and Mac OS X. +Git is written in C, Shelland Perl. It runs under Linux, BSD and Mac OS X. 
-A Windows version based on msys is avilable through the msysgit project.+A Windows version based on msys is available through the msysgit project.
  
   URL:          http://git-scm.org   URL:          http://git-scm.org
-  Mailinglist http://vger.kernel.org/vger-lists.html#git+  Mailing list: http://vger.kernel.org/vger-lists.html#git
   Wiki:         https://git.wiki.kernel.org/   Wiki:         https://git.wiki.kernel.org/
   Version:      1.7.6   Version:      1.7.6
Line 56: Line 59:
 ==== Mercurial ==== ==== Mercurial ====
 Mercurial was written by Matt Mackall in 2005. It is used by large Open Mercurial was written by Matt Mackall in 2005. It is used by large Open
-Source Projects like OpenJDK, Python and Mozilla. It is written in Python+Source Projects like OpenJDK, Python and Mozilla. It is written in Python,
 with some modules written in C for performance reasons. Mercurial is with some modules written in C for performance reasons. Mercurial is
-available for Linux, BSD, Mac OS X and Windows.  Mercurials command line+available for Linux, BSD, Mac OS X and Windows.  Mercurial'command line
 name is 'hg' - a reference to the symbol of the chemical element Mercury. name is 'hg' - a reference to the symbol of the chemical element Mercury.
  
   URL:          http://mercurial.selenic.com   URL:          http://mercurial.selenic.com
-  Mailinglist http://mercurial.selenic.com/wiki/MailingLists+  Mailing list: http://mercurial.selenic.com/wiki/MailingLists
   Wiki:         http://mercurial.selenic.com/wiki/   Wiki:         http://mercurial.selenic.com/wiki/
-  Version:      1.9+  Version:      1.9.1 
 + 
 +==== Bazaar ==== 
 +Bazaar was written by Martin Pool in 2005, when he was commissioned by Canonical 
 +to build a DVCS that "open-source hackers would love to use." It is written in 
 +Python, and is supported on Linux, Mac OS X, and Windows. Its commandline name 
 +is 'bzr'
 + 
 +Information on Bazaar in this RFC is incomplete. 
 + 
 +  URL:          http://bazaar.canonical.com 
 +  Mailing list: http://wiki.bazaar.canonical.com/BzrSupport#Mailing%20Lists 
 +  Wiki:         http://wiki.bazaar.canonical.com/ 
 +  Version:      2.3.4
  
 ===== Concepts ===== ===== Concepts =====
-While every version control system has it'own terminology, some terms +While every version control system has its own terminology, some terms are used 
-are used in every decentralized version control system. Here is a list +common to all of them. Here is a list of common definitions:
-of common defintions:+
  
 repository repository
     A collection of revisions, organized into branches     A collection of revisions, organized into branches
 clone clone
-    A complete copy of a branch or repository+    A complete copy of a branch or repository; also called a checkout
 commit commit
-    To record a revision in a repository+    A recorded revision in a repository
 merge merge
-    Apply all the changes and history from one branch or repository to another+    An application of all the changes and history in one branch to another
 pull pull
-    To update a checkout/clone from the original branch/repository, which can be +    To update a clone from the original branch/repository, whether remote or local
-    remote or local+
 push push
-    To copy revisions from one repository to another+    To copy revisions from one repository to another
  
 ==== Revision Model ==== ==== Revision Model ====
-Git and Mercurial use string representations of SHA1 checksums to identify+Git and Mercurial use string representations of SHA-1 checksums to identify
 a changeset. Both version control systems offer reserved names to access a changeset. Both version control systems offer reserved names to access
-often used changests such as the topmost commit. In both systems a user +often used changesets such as the topmost commit. In both systems a user 
 can specify only the a part of the full SHA1 as long as this part identifies can specify only the a part of the full SHA1 as long as this part identifies
 a single changeset. a single changeset.
Line 96: Line 110:
 changeset. Multiple repositories of the same project do not necessarily changeset. Multiple repositories of the same project do not necessarily
 have the same local revisions. have the same local revisions.
 +
 +Bazaar uses a more CVS-like model of monotonically increasing revision numbers,
 +with dotted notation for branches.
  
 ==== Branching Model ==== ==== Branching Model ====
Line 102: Line 119:
 Git uses pointers to a changeset to define a branch. Every ancestor of a Git uses pointers to a changeset to define a branch. Every ancestor of a
 changeset that is marked that way is part of the branch. If you delete changeset that is marked that way is part of the branch. If you delete
-the pointer the name of the branch is gone and can only be recovered +the pointerthe name of the branch is goneand can only be recovered 
-using the so called reflog if it's not yet expiered.  This means that+using the so-called "reflog", if it's not yet expired.  This means that
 you cannot bring back the name of a branch after a few years. you cannot bring back the name of a branch after a few years.
  
-Mercurial on the other side records the name of the branch in the changeset+Mercurialon the other hand, records the name of the branch in the changeset
 itself. Once you've comitted to a branch, the branch name will stay. You itself. Once you've comitted to a branch, the branch name will stay. You
-can close a branch, but you cannot remove the branchname without altering history. +can close a branch, but you cannot remove the branch name without altering 
-The drawback of this approach is that branches are not suited very well for small +history. The drawback of this approach is that branches are not suited very well 
-living test branches as naming conflicts can occur. Mercurial offers so called +for small living test branchesas naming conflicts can occur. Mercurial offers 
-Bookmarks and Anonymous Branches that work similar to Git's branching model +solutions in the form of so-called Bookmarks and Anonymous Branches, which work 
-to solve this.+similarly to Git's branching model.
  
 ===== Workflows ===== ===== Workflows =====
-The following section describes typical workflows. Note that not all subverison +The following section describes typical work flows. Note that not all Subverison 
-workflows translate one-to-one to a DVCS.+work flows translate one-to-one to a DVCS.
  
 === Setup === === Setup ===
Line 127: Line 144:
     [ui]     [ui]
     username = David Soria Parra <dsp@php.net>     username = David Soria Parra <dsp@php.net>
 +
 +== Bazaar ==
 +    bzr whoami "David Soria Parra <dsp@php.net>"
  
 === Checkout and Patch === === Checkout and Patch ===
Line 142: Line 162:
     $ hg commit     $ hg commit
     $ hg push     $ hg push
 +
 +== Bazaar ==
 +    $ bzr branch sftp://bzr.php.net/php-src
 +    .. hack Zend/zend.c ...
 +    $ bzr commit
 +    $ bzr push
  
 === Port patches across branches === === Port patches across branches ===
Line 154: Line 180:
     $ hg update default     $ hg update default
     $ hg merge PHP_5_4     $ hg merge PHP_5_4
-    or with the transplant extnesion installed+    or with the transplant extension installed
     $ hg update default     $ hg update default
     $ hg transplant a32ba2     $ hg transplant a32ba2
Line 175: Line 201:
 In some circumstances this can lead to duplicated commits that can cause In some circumstances this can lead to duplicated commits that can cause
 troubles during merges, so backporting a feature is discouraged. Try troubles during merges, so backporting a feature is discouraged. Try
-to apply a patch to the oldest currently maintained branch and merge this+to apply a patch to the oldest currently maintained branch and merge that
 branch to maintained release branches. branch to maintained release branches.
  
Line 190: Line 216:
 In some circumstances this can lead to duplicated commits that can cause In some circumstances this can lead to duplicated commits that can cause
 troubles during merges, so backporting a feature is discouraged. Try troubles during merges, so backporting a feature is discouraged. Try
-to apply a patch to the oldest currently maintained branch and merge this+to apply a patch to the oldest currently maintained branch and merge that
 branch to maintained release branches. branch to maintained release branches.
  
Line 201: Line 227:
 === Moving extension from/to core to/from pecl === === Moving extension from/to core to/from pecl ===
 We will use separate repositories for PECL and PEAR modules. php-src will We will use separate repositories for PECL and PEAR modules. php-src will
-be a separate module. We need a mechanism to move extensions from PECL to core and vice +be a separate module. We need a mechanism to move extensions from PECL to core 
-versa.+and vice versa.
  
-Both Mercurial and Git support subrepositories (called submodules in git). These are +Both Mercurial and Git support subrepositories (called submodules in git). These 
-external references to repositories. The advantage of this approach isthat it's very +are external references to repositories. The advantage of this approach is that 
-easy to add and remove modules by just modifying the external references. +it's very easy to add and remove modules by just modifying the external 
-The drawback of this approach is that you will not have a combined history log of +references. The drawback of this approach is that you will not have a combined 
-all subrepositories. Commits accross multiple subrepositories will lead so separate commits. +history log of all subrepositories. Commits across multiple subrepositories will 
-Mercurial and git will not know that these commits are related.+lead to separate commits. Mercurial and git will not know that these commits are 
 +related.
  
-An alternative to this approach is the use of subtree merges. You can +An alternative to this approach is the use of subtree merges. You can merge a 
-merge a repository into a subdirectory of a repository. This way you will +repository into a subdirectory of a repository. This way you will end up with 
-end up with the merged history beeing a full part of the repositories history. +the merged history being a full part of the repositories history. The drawback 
-The drawback of this approach is that you need depth knowledge to perform such +of this approach is that you need in-depth knowledge to perform such mergesor 
-merges or splitting repositories again. A similar approach can be used with Mercurial +to split the repositories again. A similar approach can be used with Mercurial 
-by using the convert extension and merge.+by using merge and the convert extension.
  
-In our usecase it makes more sense to use subtree merges. Moving extension from +In our use case it makes more sense to use subtree merges. Moving extensions 
-or to core doesn't happen frequently and the overhead in performing the merges and splitting +from or to core doesn't happen frequentlyand the overhead in performing the 
-is worth the benefit of having one php-src repository that contains all extensions including +merges and splitting is worth the benefit of having one php-src repository that 
-their full history.+contains all extensions and their full history.
  
 +== Git ==
 +Git supports Subtree merges, this can be used to merge stuff into an ext directory.
 +To get an extension out of core and back into pecl, you will need to use git filter-branch to extract
 +the subdirectory and regularly remove the extension with a git rm from the repo.
 +
 +== Mercurial ==
 +To move an extension into core you will first need hg convert to create a repository that
 +contains the pecl extension in a ext/ folder. Than you can merge it. If you want to move
 +an extension from core to pecl, you will need to use hg convert to extract the history
 +of the repository from php-src and then regularly remove the ext/<extension> directoy
 +with hg remove.
 ===== Tools and Platform Support ===== ===== Tools and Platform Support =====
  
 ==== Operating Systems ==== ==== Operating Systems ====
 Mercurial is available for all major platforms: Linux, BSD, Mac OS X, Mercurial is available for all major platforms: Linux, BSD, Mac OS X,
-Windows. All core features are available on supported platforms.+Windows. All core features are available on supported platforms. The same is 
 +true of Bazaar.
  
 Git is available for Linux, BSD and Mac OS X. Windows binaries based on Git is available for Linux, BSD and Mac OS X. Windows binaries based on
-msys are provided by the msysgit project. As early Git versions primarly targeted +msys are provided by the msysgit project. As early Git versions primarly 
-Linux, some commands can still be slower or even non-existant on Windows.+targeted Linux, some commands can still be slower or even non-existant on 
 +Windows. This situation is slowly improving.
  
-==== CLRF -> LF ====+==== CRLF -> LF ====
 Git supports CRLF to LF conversion. This can be configured using the variables Git supports CRLF to LF conversion. This can be configured using the variables
 core.autocrlf, core.safecrlf and gitattributes. core.autocrlf, core.safecrlf and gitattributes.
Line 246: Line 286:
 ==== Web ==== ==== Web ====
  
 +===== The PHP Karma System =====
 +PHP uses a self-implemented access control system, informally called Karma. The
 +system consists of two parts. The first part is the link to PHP user's
 +management, hosted on master.php.net. Authentication determines whether a user
 +is registered, and checks their password. Then, authorization determines whether
 +the user is allowed to commit to a particular directory.
 +
 +Under Subversion, authentication is managed with HTTP Digest authentication,
 +using data from master. Authorization is handled by a custom pre-commit hook
 +which parses the "avail" files.
 +
 +==== Authentication ====
 +Both Git and Mercurial support SSH and HTTP. We will focus on HTTP, as we cannot
 +manage SSH keys for all users that have access to the PHP repository. HTTP will
 +also enable push and pull through most corporate firewalls.
 +
 +=== Git ===
 +Git can use HTTP Basic auth to verify whether a user is allowed to login. We
 +can use HTTP Digest for authentication and an ''update'' hook to check whether
 +the user is authorized to push to that directory.
 +
 +=== Mercurial ===
 +Mercurial can use HTTP basic auth. We can use HTTP Digest for authentication and
 +a hook to check if the user has the necessary access rights.
 +An implementation of the PHP karma system as a Mercurial plugin exists. It can be found here:
 +https://bitbucket.org/segv/php-karma-hook
 +
 +==== General Server Layout ====
 +        
 +        user <-- KARMA CHECK --> hg/git.php.net <-- MIRRORING --> github/bitbucket
 +        
 ===== Unqiue features ===== ===== Unqiue features =====
 ==== Git ==== ==== Git ====
Line 255: Line 326:
 directory (see: git add -p). The drawback of this approach is that you directory (see: git add -p). The drawback of this approach is that you
 have to manually stage a change or use the --all switch in git commit. have to manually stage a change or use the --all switch in git commit.
-While this is a powerful feature, it can confuse people comming from+While this is a powerful feature, it can confuse people coming from
 other version control systems. other version control systems.
  
-=== Separate Author and Committer === +=== Separate Author and Commiter === 
-Git separates author and committer and records both in changeset. A +Git separates author and commiter, and records both in each changeset. A 
-commit can have a different author than a committer. This is useful +commit can have a different author and committer. This is useful for PHPas a 
-for PHP as a patch from the mailinglist will be committed with the +patch from the mailing list will be committed with the original author and the 
-original author and the information who committed it, making it easier +information of committed it, making it easier to identify the original patch 
-to identifier who wrote the patch initially.+author.
  
 ==== Mercurial ==== ==== Mercurial ====
 === Local Revision Numbers === === Local Revision Numbers ===
-Both Git and Mercurial use SHA1 to identify a changeset and ensure it's +Both Git and Mercurial use SHA1 to identify a changeset and ensure that it is 
-globally unique. The string representation of a SHA1 is the revision +globally unique. The string representation of a SHA1 hash is the revision 
-number. Incremented integers cannot identify a changeset globally but+number. Incrementing integers cannot identify a changeset globallybut
 they are useful shortcuts in local repositories. they are useful shortcuts in local repositories.
  
-Mercurial uses incremented integers, similar to SVN revision numbers +Mercurial uses incrementing integers, similar to SVN revision numberson 
-on changesets. These can be used on a local repository to identify a +changesets. These can be used on a local repository to identify a revision. Git 
-revision. Git only supports SHA1.+supports only SHA1
 + 
 +Bazaar uses CVS-style incrementing integers as revision numbers.
  
 Changeset Changeset
Line 287: Line 360:
  
 has the local revision number 75485 and the global 61e266b471e4. has the local revision number 75485 and the global 61e266b471e4.
-=+
 === Revsets and Filesets === === Revsets and Filesets ===
 Mercurial has a powerful query language to select changests or files to Mercurial has a powerful query language to select changests or files to
 include in log, diff and similar commands. For example, to search for include in log, diff and similar commands. For example, to search for
-the last tagged revision that includes a given changeset you can run+the last tagged revision that includes a given changesetyou can run
 the following query: the following query:
  
Line 297: Line 370:
  
 === Extensions === === Extensions ===
-Mercurial is written in Python and supports loading and executing +Mercurial is written in Pythonand supports loading and executing 
-Mercurial extensions written in Python that can access the internal+extensions written in Python. These extensions can access the internal
 Mercurial API. Mercurial API.
  
 Mercurial extensions are a common way to implement additional features Mercurial extensions are a common way to implement additional features
-such as rebase, commit signatures and access control. Mercurial ships+such as rebase, commit signaturesand access control. Mercurial ships
 with a set of core extensions. A full list of extensions can be found with a set of core extensions. A full list of extensions can be found
 in the Mercurial wiki. in the Mercurial wiki.
Line 319: Line 392:
  
 ===== Hosting Infrastructure ===== ===== Hosting Infrastructure =====
-The main repository will be hosted at php.net. This will make implementing infrastructure +The main repository will be hosted at php.net. This will make implementing 
-or scripts easier and gives us full power over our development environment.+infrastructure or scripts easierand gives us full power over our development 
 +environment.
  
-Other hosting sites can be used to attract more developers. DVCS make it easy to push +Other hosting sites can be used to attract more developers. DVCS make it easy to 
-a repository to different locations and keep them in sync.+push a repository to different locations while keeping them all in sync.
  
 ==== Git / Github ==== ==== Git / Github ====
Line 360: Line 434:
  
 === Subversion Integration === === Subversion Integration ===
-Bitbucket supports a SVN bridge. You can checkout and commit to +Bitbucket supports a SVN bridge. You can checkout and commit to a repository 
-a repository using SVN.  The subversion integration is in beta +using SVN.  The subversion integration is in beta phase. Commits can fail under 
-phase. Commits can fail under certain circumstances.+certain circumstances.
  
 ===== Implementation ===== ===== Implementation =====
Line 368: Line 442:
 can influence the decision are outlined in this RFC. can influence the decision are outlined in this RFC.
  
-We will not convert the whole SVN repository at once.  As Git and +We will not convert the whole SVN repository at once.  As Git and Mercurial do 
-Mercurial do not allow checkouts of subdirectories. We have to split up +not allow checkouts of subdirectories, we will have to split the repository into 
-the repository into modules. To guarantee minimal downtimes and having +modules, a move which is already desired. To guarantee minimal downtimes and a 
-smooth transition, we will move module after module. The first module will+smooth transition, we will move one module at a time. The first module will
 be php-src and the karma system. Other modules like systems will follow. be php-src and the karma system. Other modules like systems will follow.
 +
 +As DVCS does not support cloning of subtrees of a repository, we will split the
 +repository similar to the old CVS structure. References to other repositories can
 +be maintained using the submodules/subrepositories feature as described above. If necessary
 +subtree merges will be done to maintain better history and easier cloning.
 +
 +For every module like phpdoc, php-src, web and so on an own implementation RFC will be written.
 +
 +In general, modules will be accessible via HTTP on git/hg.php.net. Every module will be it's own repository, e.g
 +http://hg.php.net/repositories/php-src http://hg.php.net/repositories/pecl-http.
 +A web interface to browse the code will be available. Note that a combined checkout of PECL modules or similar
 +SVN directories will not be available. If necessary, we can create meta repositories that have
 +references to those repositories manually.
 +
 +==== php-src ====
 +The first source to be moved to the chosen DVCS will be php-src. Other modules, such as web,
 +pecl and phpdoc will follow later.
 +
 +==== PECL, PHPdoc and co ====
 +Modules like PECL can use submodules/subrepositories to maintain references to each other. If a PECL
 +modules moves to php-src it will be either done as a submodules/subrepository or using subtree merges
 +to maintain a combined history and ease the cloning process. To easy the process, if PECL modules are
 +maintained outside of php.net they should try to use the same VCS as PHP.
  
 ==== Migration RFC ==== ==== Migration RFC ====
 The migration of modules is handled through the following RFCs: The migration of modules is handled through the following RFCs:
  
-  - Migration of php-src and KARMA+  - Migration of php-src 
 +  - Migration of phpdoc 
 +  - Migration of PECL
  
 more to follow. more to follow.
  
-===== Discussion ==== +===== Discussion and Recommendation ==== 
-In this section I'll try to outline some qualitative evaluation based on discussion that I had about this topic with people from +In this section I'll try to outline some qualitative evaluation based on 
-the PHP community and with other users of Git and Mercurial.+discussions that I had about this topic with people from the PHP community and 
 +with other users of Git and Mercurial.
  
-It seems that Mercurial is considered easier to learn when coming from Subversion. It'extension system keeps the core commands +It seems that Mercurial is considered easier to learn when coming from 
-simple while advanced users can add more features. This extensibility can be useful when it comes to implementing the Karma system +Subversion. Its extension system keeps the core commands simplewhile advanced 
-or documentation related translation synchronization. Mercurial comes with excellent Windows support. It also has very capable +users can add more features. This extensibility can be useful when it comes to 
-HTTP support making it easy for people to pull and push through proxies. The ui is kept simple and Mercurial does not expose +implementing the Karma systemor documentation-related translation 
-low level commands. For people without much knowledge about version control systems and people coming from Subversion, Mercurial +synchronization. Mercurial comes with excellent Windows support. It also has 
-is more suitable than Git.+very capable HTTP supportmaking it easy for people to pull and push through 
 +proxies. The UI is kept simpleand Mercurial does not expose low-level 
 +commands. For people without much knowledge about version control systemsand 
 +people coming from Subversion, Mercurial is more suitable than Git.
  
-Git is considered the most used DVCS in the Open Source community. Git does not have a plugin system, but the Karma system can be +Git is considered the most used DVCS in the Open Source community. Git does not 
-implemented through push and pull hooks. Git offers HTTP support that can be used to push and pull through a proxy. Newer Git versions +have a plugin system, but the Karma system can be implemented through push and 
-offer a smart HTTP protocol, that can be considered equally good as the Mercurial HTTP support. Due to it'history concepts and the large set +pull hooks. Git offers HTTP support that can be used to push and pull through a 
-of commands, git has a higher learning curve than similar systems. Git is widely used by Open Source projects written in PHP, such as Zend Framework, +proxy. Newer Git versions offer a smart HTTP protocol which can be considered 
-Symphony 2, phpBB and xdebug. The most important argument in favour of Git, however, is not git itself, but Github. It has a large user base +equal to Mercurial'HTTP support. Due to its historyconceptsand the large 
-and makes it very easy for people to participate on a project. It'far more popular than Bitbucket.+set of commands, Git has a higher learning curve than similar systems. Git is 
 +widely used by Open Source projects written in PHP, such as Zend Framework, 
 +Symphony 2, phpBBand xdebug. The most important argument in favor of Git, 
 +however, is not Git itself, but Github. It has a large user baseand makes it 
 +very easy for people to participate on a project. It is far more popular than 
 +Bitbucket.
  
-Asked for a evaluation which system to choose in the end, I personally would lean towards GitIt seems that a lot of developers already know +Migrating history can be easily done in both DVCSThe Karma system can be implemented 
-GitAlso Github is a very important factor to enable people to contribute to PHP.+in both DVCSThere is no show stopper on both DVCS.
  
 +My personal opinion is that Mercurial is easier to learn. SVN concepts
 +translate better to Mercurials concepts, e.g. local incrementing revision numbers.
 +Developers. that already know Git won't have a big problem to use Mercurial.
 +I think Mercurial would be the better fit. It also gives us more flexibility
 +in case we want to write additional extensions for the phpdoc team or whatever.
  
 ===== Further Readings and References ===== ===== Further Readings and References =====
Line 407: Line 520:
  
 Further Readings: Further Readings:
 +  * a successful git branching model http://nvie.com/posts/a-successful-git-branching-model/
   * http://progit.com (Book about Git)   * http://progit.com (Book about Git)
   * http://mercurial.selenic.com (Mercurial Website and Guides)   * http://mercurial.selenic.com (Mercurial Website and Guides)
   * http://git-scm.org (Git Website)   * http://git-scm.org (Git Website)
   * http://www.python.org/dev/peps/pep-0374/ (Python PEP to choose a DVCS. This RFC is heavily inspired by the PEP)   * http://www.python.org/dev/peps/pep-0374/ (Python PEP to choose a DVCS. This RFC is heavily inspired by the PEP)
 +  * http://hginit.com
  
-===== Changelog ===== +Discussion on internals: 
 +  * git anyone? - http://www.mail-archive.com/internals@lists.php.net/msg48595.html 
 +  * DVCS - http://www.mail-archive.com/internals@lists.php.net/msg50137.html 
 +  * Choosing a distributed version control system for PHP (or not). Call for Participation. - http://www.mail-archive.com/internals@lists.php.net/msg52523.html 
 +  * moving forward - http://www.mail-archive.com/internals@lists.php.net/msg45385.html 
 +  * Hold off 5.4 - http://www.mail-archive.com/internals@lists.php.net/msg48579.html 
 +  * Project Management - http://www.mail-archive.com/internals@lists.php.net/msg48865.html 
 +  * CVS to SVN Migration - http://www.mail-archive.com/internals@lists.php.net/msg37519.html 
 +  * Volunteers for Subversion 1.5 conversion of cvs.php.net? - http://www.mail-archive.com/internals@lists.php.net/msg37509.html
  
 +===== Changelog =====
  
 +  * 2011-07-30: initial revision
 +  * 2011-08-07: general cleanup and a small amount of Bazaar information
 +  * 2011-08-26: add reference to hginit.com
rfc/dvcs.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1