rfc:dvcs

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:dvcs [2011/08/11 18:23]
dsp Karma system implemention for Mercurial ready.
rfc:dvcs [2017/09/22 13:28] (current)
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 250: Line 250:
 contains all extensions and 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 =====
  
Line 262: Line 273:
 Windows. This situation is slowly improving. 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 301: Line 312:
 An implementation of the PHP karma system as a Mercurial plugin exists. It can be found here: An implementation of the PHP karma system as a Mercurial plugin exists. It can be found here:
 https://​bitbucket.org/​segv/​php-karma-hook 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 429: Line 445:
 not allow checkouts of subdirectories,​ we will have to split the repository into not allow checkouts of subdirectories,​ we will have to split the repository into
 modules, a move which is already desired. To guarantee minimal downtimes and a modules, a move which is already desired. To guarantee minimal downtimes and a
-smooth transition, we will move one module at at ime. 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 In this section I'll try to outline some qualitative evaluation based on
 discussions that I had about this topic with people from the PHP community and discussions that I had about this topic with people from the PHP community and
Line 465: Line 506:
 very easy for people to participate on a project. It is far more popular than very easy for people to participate on a project. It is far more popular than
 Bitbucket. Bitbucket.
 +
 +Migrating history can be easily done in both DVCS. The Karma system can be implemented
 +in both DVCS. There 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 470: 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
  
 Discussion on internals: Discussion on internals:
Line 489: Line 541:
   * 2011-07-30: initial revision   * 2011-07-30: initial revision
   * 2011-08-07: general cleanup and a small amount of Bazaar information   * 2011-08-07: general cleanup and a small amount of Bazaar information
 +  * 2011-08-26: add reference to hginit.com
rfc/dvcs.1313086981.txt.gz · Last modified: 2017/09/22 13:28 (external edit)