Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52637
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=JWj7MW7LcYUwNut1l5QzGJRJPOe1XwTn6rzBhc1NPHD573L6r3t9eOSQtpyhR0fkVM
         JTJRRQ0qqyHBv4FDpsTQdbmwbn93r4DIXfUHFxnvBKgGbqYtSj2rsbwThWQjOQmiiInu
         1fFrXAY+hoEHEZ+7mPDMsraunhcLGZN0dSzpE=
MIME-Version: 1.0
In-Reply-To: <4DE5EC35.1080401@lsces.co.uk>
References: <4DB8CCA9.7040604@yahoo.com.au> <BANLkTik+wffarxWj-hzm_uHf2b70dUb_jw@mail.gmail.com>
 <BANLkTinZewZVgmNqzw_4tOs3ShmaxOcnrA@mail.gmail.com> <4DB9170E.7010707@lsces.co.uk>
 <BANLkTinkkhOBp+W7a2HDj89Rf4jWw0t5Lw@mail.gmail.com> <4DE5E291.9050806@lsces.co.uk>
 <BANLkTimaRDY-=fdcwXFD-Frwh4=_-RTedQ@mail.gmail.com> <4DE5EC35.1080401@lsces.co.uk>
Date: Wed, 1 Jun 2011 02:55:14 -0500
Message-ID: <BANLkTiko1NU6UiWsjmUC+tdTWveFKUqJiQ@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001485f91cd26720ab04a4a1d816
Subject: Re: [PHP-DEV] DVCS
From: dukeofgaming@gmail.com (dukeofgaming)

--001485f91cd26720ab04a4a1d816
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 1, 2011 at 2:37 AM, Lester Caine <lester@lsces.co.uk> wrote:

> Drak wrote:
>
>>    At the current time I think that PHP would need to restructure how
>>    it is packaged up to provide a single repo in both HG or GIT.
>>    Keeping SVN ( I'd still prefer CVS here it works BETTER as a master
>>    for DVCS! ) as the master from which we CAN currently sync using HG
>>    or GIT is the best of a bad job currently. Unless some knows better
>>
>> I know what you mean.  There are solutions like submodules in GIT but it
>> does require some small restructuring usually.  By the way, TortoiseGIT
>> is now quite excellent for Windows GUI.  A new version 1.7.0 is just
>> about to be released too.  I'm a bit biased against GIT but overall, GIT
>> is getting way more traction than Hg and github.com <http://github.com>
>>
>> excels in features compared to anything else.
>>
> When TortoiseGIT runs in Linux as well - they will have caught up!
> TortoiseHg works transparently in both and on Mac I believe. My customer
> base is mainly windows biased while I've been running on Linux here for some
> years now. I need both platforms to do the same thing - which Eclipse has
> provided for several years, but the DVCS camps still need to address.
> Windows GIT is something different from Linux GIT at the moment - which is
> probably all that is putting me off it. Actually when I was forced to used
> GIT the windows side simply did not work at all, so I HAD to use hggit to
> get anything!
>
>
>   From what I have seen also, IDE integration with GIT is starting to
>> catchup both in NetBeans and Eclipse - and already way ahead of the pack
>> is phpStorm for VCS integration, but it's not free.
>>
> hggit + Mercurial Eclipse + Eclipse means I could not care less what the
> target is EXCEPT that one can't write a project that is JUST the set of
> sub-modules that you want to pull together. IDEALLY - both GIT and HG would
> just pull stuff from which ever is providing a particular library? So say
> Smarty could be on one while ADOdb is on the other ... The core PHP code
> does not need to be so distributed, but being able to pull PECL modules from
> a number of sources to add to a core clone of the code could be useful?
>
>
Perhaps, it would depend how teams are structured, but even it was a single
repository for everything I think stuff would work fine.

My opinion is that the reason behind sub-repositories is to include code
from vendors, not that much to modularize development of a single big
project, why?, because of the distributed nature of a DVCS: imagine that
there is a PECL team, and that team makes a fork of the main PHP repository,
and they focus on that "fork" (every separate repository can be regarded as
a fork) and they handle all their work integration, and then someone (after
an ammount of work is done) pulls back from the main repo (the one where
last integrations are agreed to be added, "central" if you must call it
that) to ensure everything still runs ok, and then ask to the final
integrator to pull and merge their work: done.

Oh, and HG supports svn and git as subrepos now.

Regards,

David

--001485f91cd26720ab04a4a1d816--