Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54570
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain managedit.ie designates 209.85.210.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E4644EE.9@lsces.co.uk>
References: <slrnj3tulc.6vi.dsp@experimentalworks.net> <CAKUjMCUirzSjVs7GvaZmWmhx2W=h6OGyOX0YKPnUHztRkZc5xQ@mail.gmail.com>
 <4E3F02E8.2050402@sugarcrm.com> <alpine.DEB.2.02.1108121119420.4043@whisky>
 <CAH-PCH4YO1e-+=+38DrhwUe-nR9akJ+c=64vk0ar3GZGM5YOmw@mail.gmail.com>
 <4E450EB1.6090502@lsces.co.uk> <4E456F2F.7030809@sugarcrm.com>
 <4E45755F.3020005@lsces.co.uk> <4E4578B6.6050708@sugarcrm.com>
 <4E45A2BD.7060506@lsces.co.uk> <4E45AFDF.9000001@sugarcrm.com>
 <4E45B6A9.9080607@lsces.co.uk> <CAGSj+QtJ-XdNWhpKMR44WLjS5eNh_EiwuOcM7=aR=JugWHZz2A@mail.gmail.com>
 <CAEZPtU45hGm4STEU8xQvjA8NkjUCaQ8ex8vWKFrWrLzMcrH7tg@mail.gmail.com>
 <4E462F94.6090104@lsces.co.uk> <4E46391E.8080609@s1998.tu-chemnitz.de> <4E4644EE.9@lsces.co.uk>
Date: Sat, 13 Aug 2011 14:40:02 +0100
Message-ID: <CAGSj+QsRemRX8aVX1ya3fa4vcS1XBMTbY05+ORvsdZLpurK7Hw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec52e5f13e9ef1604aa632b67
Subject: Re: [PHP-DEV] [RFC] Choosing a distributed version control system for
 PHP (or not). Call for Participation.
From: kiall@managedit.ie (Kiall Mac Innes)

--bcaec52e5f13e9ef1604aa632b67
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Aug 13, 2011 at 10:33 AM, Lester Caine <lester@lsces.co.uk> wrote:

> I don't have a problem with DVCS, just with projects ploughing into using
> git a year ago when it was ( and still is ) not ready for those type of
> projects :(
>

I think you're talking about submodules not being ready - correct me if I'm
wrong.

We (the Kohana <http://kohanaframework.org> framework and my company) use
git submodules very successfully to track isolated parts of the code.
Submodules work perfectly.

https://github.com/kohana/kohana/blob/3.2%2Fmaster/.gitmodules

It was a case of having to work with it at a time when cross platform tools
> were not available, and subrepo's did not exist.
>

I've occasionally used msysgit on windows for Kohana development - cross
platform submodules have work perfectly for years!

And - I've never heard a complaint from anyone about Git for OS X / Linux
not working correctly.


> I have a nice working hg setup that works transparently from Linux and
> Windows and runs in parallel with my Eclipse development platform. But even
> that still has not restored some of the excellent tools that CVS and SVN
> provide in Eclipse. MANY of the complaints about CVS and SVN were never a
> problem when one used Eclipse. At some point I expect the same facilities to
> be restored to Eclipse, but currently TortoiseHg runs in parallel neatly. I
> don't have to switch between different tools on the different platforms.


In my experience, no GUI VCS tools (for Git/SVN/CVS) have ever measured up
to the easy of use, and power of the CLI versions. And honestly - I think
choosing a VCS based on the available GUI tools is poor decision making. New
and improved GUI's will continue to be released, while the core VCS will
remain a relatively stationary target.

Again, I'm not explaining things very well ...
> What will not work moving forward is a simple dump of the entire SVN
> history into a single git repository. What is needed is a managed way to
> create a series of subrepos for each of the packages that make up PHP.


This has been briefly discussed in the RFC, and I believe the intention is
to cover that in detail in a second "Migration RFC". I don't believe anyone
is suggesting a simple dump of SVN into Git/Hg.


> PECL and PEAR packages then just become extra subrepos which are included
> or not in the superproject trunk. The 'single repo' camp point to "feature
> branch" as a way of handling that work in a single module without having to
> breaking up the repo


I don't believe that's what anybody is suggesting (besides - I think - the
Drupal document you referenced).

I believe people are suggesting that feature/topic branches might be used
within a single repo. For example the pecl APC repo might have a "master"
(trunk) branch, and a "feature/persistent-opcode-cache" branch.

Kiall

--bcaec52e5f13e9ef1604aa632b67--