rfc:dvcs
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:dvcs [2011/08/07 20:15] – a first note about the karma system dsp | rfc: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: | + | * 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: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
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. | + | moment. |
- | can solve some of these drawbacks. This RFC aims to provide information | + | can solve some of these drawbacks. This RFC aims to provide information |
- | choose | + | in choosing |
===== Current Situation ===== | ===== Current Situation ===== | ||
- | Subversion is used to host the main PHP repository | + | Subversion is used to host the main PHP repository, as well as several |
- | PEAR and PECL. Access is granted | + | sub-projects such as PEAR and PECL. Access |
- | Using Subversion has drawbacks: | + | through |
- | * requires network access | + | |
+ | Using Subversion has several | ||
+ | * requires network access | ||
* slow log/ | * slow log/ | ||
* large checkout sizes | * large checkout sizes | ||
* single point of failure | * single point of failure | ||
* painful merging | * painful merging | ||
- | * no implizit | + | * no implicit |
- | 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/ |
* no single point of failure, easy to setup multiple hosting | * no single point of failure, easy to setup multiple hosting | ||
* advanced features such as rebase to linearise history, bisect to find regression bugs | * advanced features such as rebase to linearise history, bisect to find regression bugs | ||
* " | * " | ||
- | Decentralized version control | + | Decentralized version control |
* no partial checkout of subdirectories | * no partial checkout of subdirectories | ||
* no empty directories, | * no empty directories, | ||
- | * no global unique incrementing rev numbers, | + | * no global unique incrementing rev numbers, |
- | * no svn: | + | * no svn: |
+ | |||
+ | ===== Overview of Competitors ===== | ||
- | ===== Overview Competitors ===== | ||
==== Git ==== | ==== Git ==== | ||
- | Git was written by Linus Torvalds as a replacement for BitKeeper | + | 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 | + | 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, Shell, and Perl. It runs under Linux, BSD and Mac OS X. |
A Windows version based on msys is available through the msysgit project. | A Windows version based on msys is available through the msysgit project. | ||
URL: http:// | URL: http:// | ||
- | | + | |
Wiki: | Wiki: | ||
Version: | Version: | ||
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. | + | available for Linux, BSD, Mac OS X and Windows. |
name is ' | name is ' | ||
URL: http:// | URL: http:// | ||
- | | + | |
Wiki: | Wiki: | ||
- | Version: | + | Version: |
+ | |||
+ | ==== Bazaar ==== | ||
+ | Bazaar was written by Martin Pool in 2005, when he was commissioned by Canonical | ||
+ | to build a DVCS that " | ||
+ | Python, and is supported on Linux, Mac OS X, and Windows. Its commandline name | ||
+ | is ' | ||
+ | |||
+ | Information on Bazaar in this RFC is incomplete. | ||
+ | |||
+ | URL: http:// | ||
+ | Mailing list: http:// | ||
+ | Wiki: | ||
+ | Version: | ||
===== Concepts ===== | ===== Concepts ===== | ||
- | While every version control system has it' | + | While every version control system has its own terminology, |
- | 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 definitions: | + | |
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 | ||
- | | + | |
merge | merge | ||
- | | + | |
pull | pull | ||
- | To update a checkout/clone from the original branch/ | + | To update a clone from the original branch/ |
- | | + | |
push | push | ||
- | To copy a 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 changesets such as the topmost commit. In both systems a user | often used changesets such as the topmost commit. In both systems a user | ||
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 pointer, the name of the branch is gone, and can only be recovered |
- | using the so called reflog if it's not yet expired. | + | using the so-called |
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 | + | Mercurial, on 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 branch name 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 branches, as naming conflicts can occur. Mercurial offers |
- | Bookmarks and Anonymous Branches | + | solutions in the form of so-called Bookmarks and Anonymous Branches, which work |
- | to solve this. | + | similarly |
===== Workflows ===== | ===== Workflows ===== | ||
Line 127: | Line 144: | ||
[ui] | [ui] | ||
username = David Soria Parra < | username = David Soria Parra < | ||
+ | |||
+ | == Bazaar == | ||
+ | bzr whoami "David Soria Parra < | ||
=== Checkout and Patch === | === Checkout and Patch === | ||
Line 142: | Line 162: | ||
$ hg commit | $ hg commit | ||
$ hg push | $ hg push | ||
+ | |||
+ | == Bazaar == | ||
+ | $ bzr branch sftp:// | ||
+ | .. hack Zend/zend.c ... | ||
+ | $ bzr commit | ||
+ | $ bzr push | ||
=== Port patches across branches === | === Port patches across branches === | ||
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 is, that 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 across 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 being 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 a depth knowledge to perform such | + | of this approach is that you need in-depth knowledge to perform such merges, or |
- | merges or splitting | + | to split the repositories again. A similar approach can be used with Mercurial |
- | by using the convert extension | + | by using merge and the convert extension. |
- | In our use case it makes more sense to use subtree merges. Moving | + | In our use case it makes more sense to use subtree merges. Moving |
- | or to core doesn' | + | from or to core doesn' |
- | is worth the benefit of having one php-src repository that contains all extensions | + | merges and splitting is worth the benefit of having one php-src repository that |
- | their full history. | + | contains all extensions |
+ | == 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/< | ||
+ | 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 | + | 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 |
+ | 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.autocrlf, | ||
Line 247: | Line 287: | ||
===== The PHP Karma System ===== | ===== The PHP Karma System ===== | ||
- | PHP uses a self implemented access control system, | + | PHP uses a self-implemented access control system, |
- | of two parts. The first part is the link to the PHP user management. | + | system consists |
- | in the PHP user system | + | management, hosted on master.php.net. Authentication determines whether |
- | to commit to the directory | + | is registered, and checks their password. Then, authorization |
+ | the user is allowed to commit to a particular | ||
+ | |||
+ | Under Subversion, authentication is managed with HTTP Digest authentication, | ||
+ | using data from master. Authorization is handled by a custom pre-commit | ||
+ | which parses the " | ||
==== Authentication ==== | ==== 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 | + | Both Git and Mercurial support SSH and HTTP. We will focus on HTTP, as we cannot |
- | access to the PHP repository. | + | 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 === | ||
- | Git can use HTTP basic auth to verify | + | Git can use HTTP Basic auth to verify |
- | PHP user management. | + | can use HTTP Digest for authentication and an '' |
+ | the user is authorized to push to that directory. | ||
=== Mercurial === | === Mercurial === | ||
- | Mercurial can use HTTP basic auth. It is possible to write an extension to hook up with the PHP User Management | + | 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 | ||
+ | https:// | ||
+ | ==== General Server Layout ==== | ||
+ | | ||
+ | user <-- KARMA CHECK --> hg/ | ||
+ | | ||
===== Unqiue features ===== | ===== Unqiue features ===== | ||
==== Git ==== | ==== Git ==== | ||
Line 276: | Line 330: | ||
=== Separate Author and Commiter === | === Separate Author and Commiter === | ||
- | Git separates author and commiter and records both in a changeset. A | + | Git separates author and commiter, and records both in each changeset. A |
- | commit can have a different author | + | commit can have a different author |
- | for PHP as a patch from the mailinglist | + | patch from the mailing list will be committed with the original author and the |
- | original author and the information | + | information |
- | 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 |
- | globally unique. The string representation of a SHA1 is the revision | + | globally unique. The string representation of a SHA1 hash is the revision |
- | number. | + | number. |
they are useful shortcuts in local repositories. | they are useful shortcuts in local repositories. | ||
- | Mercurial uses incremented | + | Mercurial uses incrementing |
- | 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 |
+ | |||
+ | Bazaar uses CVS-style incrementing integers as revision numbers. | ||
Changeset | Changeset | ||
Line 304: | 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 changeset, you can run |
the following query: | the following query: | ||
Line 314: | Line 370: | ||
=== Extensions === | === Extensions === | ||
- | Mercurial is written in Python and supports loading and executing | + | Mercurial is written in Python, and supports loading and executing |
- | Mercurial | + | extensions written in Python. These extensions |
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 signatures, and 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 336: | Line 392: | ||
===== Hosting Infrastructure ===== | ===== Hosting Infrastructure ===== | ||
- | The main repository will be hosted at php.net. This will make implementing | + | 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 |
+ | 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 | + | push a repository to different locations |
==== Git / Github ==== | ==== Git / Github ==== | ||
Line 377: | 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 385: | 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 | + | smooth transition, we will move one module |
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/ | ||
+ | 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/ | ||
+ | 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/ | ||
+ | modules moves to php-src it will be either done as a submodules/ | ||
+ | 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 | + | - Migration of php-src |
+ | - Migration of phpdoc | ||
+ | - Migration of PECL | ||
more to follow. | more to follow. | ||
- | ===== Discussion ==== | + | ===== Discussion |
- | In this section I'll try to outline some qualitative evaluation based on discussion | + | 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 |
+ | with other users of Git and Mercurial. | ||
- | It seems that Mercurial is considered easier to learn when coming from Subversion. | + | 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. |
- | or documentation related translation synchronization. Mercurial comes with excellent Windows support. It also has a 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 system, or 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 support, making it easy for people to pull and push through |
+ | proxies. The UI is kept simple, and Mercurial does not expose low-level | ||
+ | commands. For people without much knowledge about version control systems, and | ||
+ | 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 | + | pull hooks. Git offers HTTP support that can be used to push and pull through a |
- | of commands, | + | proxy. Newer Git versions offer a smart HTTP protocol |
- | Symphony 2, phpBB and xdebug. The most important argument in favour | + | equal to Mercurial' |
- | and makes it very easy for people to participate on a project. It' | + | set of commands, |
+ | widely used by Open Source projects written in PHP, such as Zend Framework, | ||
+ | Symphony 2, phpBB, and xdebug. The most important argument in favor of Git, | ||
+ | however, is not Git itself, but Github. It has a large user base, and 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 | + | Migrating history can be easily done in both DVCS. The Karma system can be implemented |
- | Git. Also Github | + | 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 424: | Line 520: | ||
Further Readings: | Further Readings: | ||
+ | * a successful git branching model http:// | ||
* http:// | * http:// | ||
* http:// | * http:// | ||
* http:// | * http:// | ||
* http:// | * http:// | ||
+ | * http:// | ||
- | ===== Changelog ===== | + | Discussion on internals: |
+ | * git anyone? - http:// | ||
+ | * DVCS - http:// | ||
+ | * Choosing a distributed version control system for PHP (or not). Call for Participation. - http:// | ||
+ | * moving forward - http:// | ||
+ | * Hold off 5.4 - http:// | ||
+ | * Project Management - http:// | ||
+ | * CVS to SVN Migration - http:// | ||
+ | * Volunteers for Subversion 1.5 conversion of cvs.php.net? | ||
+ | ===== 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.1312748141.txt.gz · Last modified: 2017/09/22 13:28 (external edit)