Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54571
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.187 cause and error)
Message-ID: <4E468A36.5010306@lsces.co.uk>
Date: Sat, 13 Aug 2011 15:29:10 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110420 SUSE/2.0.14-2.2 SeaMonkey/2.0.14
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
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> <CAGSj+Qs-imY+OXdy0z+ityvPc0DZgWkkaURzY7XN0Txmi7JoJA@mail.gmail.com>
In-Reply-To: <CAGSj+Qs-imY+OXdy0z+ityvPc0DZgWkkaURzY7XN0Txmi7JoJA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Choosing a distributed version control system
 for PHP (or not). Call for Participation.
From: lester@lsces.co.uk (Lester Caine)

Kiall Mac Innes wrote:
> I have to agree with you on this - I for one have been very confused by
> Lester's comments!
>
> One choice example I've just realised, is most of us are taking about the
> workflows of Git/Hg for PHP itself, sometimes using PHP based projects as
> simple workflow examples.

It does depend where you separate the C code from the PHP ... but with the right 
workflow it should not matter which code is being worked on? Just developing a 
process that only handles C development then ignores the PEAR arm. Once one 
covers that, there is little difference to managing the development of the whole 
site set-up. In theory the DVCS could also manage all of the documentation as well.

I'm playing with C and C++ code in parallel to the PHP, javascript, and other 
web languages and in addition java and python to improve the tools such as 
PHPEclipse and Hg itself. It's only in the last month or so ( since hg1.9 and 
other updates ) that the whole package has started to flow as well as the 
original CVS workflow that has been fine for me for 10+ years ...

Eclipse has provided a clean stable platform across both Linux and Windows so 
I've never actually had to learn command line stuff. Both git and hg are 
essentially command line tools which are only now being supported by the same 
extended facilities that CVS and SVN have had for many years! A year ago there 
was a very clear distinction between git and hg once one moved away from the 
command line, but on the command line there was very little difference? Nowadays 
things are a lot tighter, but none of the options stand out as the right 
solution, they all have as many negatives as positives, so the target should be 
a process that does not prevent any DVCS client from being used. If the master 
is on git then so be it, just don't then put in place processes that prevent hg 
or one of the other DVCS systems from cooperating as well?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php