Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54567
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.127 cause and error)
Message-ID: <4E4644EE.9@lsces.co.uk>
Date: Sat, 13 Aug 2011 10:33:34 +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>
In-Reply-To: <4E46391E.8080609@s1998.tu-chemnitz.de>
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)

Michael Grunert wrote:
> On 08/13/2011 10:02 AM, Lester Caine wrote:
>> Looking back, the point that I was not explaining very well was the fact
>> that people seem to think that they need to create a fork into their
>> on-line account before cloning to the local copy. On the whole these are
>> not needed, and the 'sandbox' approach for sharing tangential work seems
>> better? Similarly extensions like apt have their own subrepo which can
>> be worked on independent to the bulk of the code base?
>
> Just to throw in some comment, you did a really good job to confuse
> people in this thread. In the beginning i really got the impression you
> were totally against dvcs and now you praise them and argue in their
> favor against people who want them too .. maybe i just misread some of
> the mails but thats my overall impression so far ..

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 :(
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 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.

>>> About branching, tagging or developing using a DVCS, I can only
>>> recommend to read the doc linked in this rfc:
>>>
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>
>>> It explains one model which has been proven to work pretty well.
>> This model is ideal for a main trunk. The major advantage to DVCS is
>> being able to work on things like PECL modules and even core extensions
>> in parallel to the main core. It is only recently that git and hg have
>> finally supported 'subrepo' and I see this as the ideal model for my own
>> work. I can create a superproject which just combines the extensions
>> (php and third party!) that I am using and almost manage them nicely.
>> There are still a few rough edges to this since neither git nor hg have
>> been convinced that it is an important requirement ... they don't use it
>> themselves which seems strange when their own code base has many third
>> party elements? I don't see 'feature branches' as the correct way to
>> handle what are essentially self contained elements?
>
> So did you read the workflow document? I do have some doubt there ..
> A "feature branch" does not refer to some self contained element you
> could or even should place into a subrepo like a pecl extension or
> module. A "feature branch" is meant for a distinct unit of work, like a
> new feature or a bug fix that has to be merged with the main branch
> sometime in the future anyways. As soon as this feature or bug fix has
> been completed the feature branch dies/dries up .. which is obviously
> bad in something like svn as those branches would clutter up the
> repository but can be handled really good in dvcs as the new branches
> are only local or in some loosely coupled public forks/clones and can be
> pulled/pushed into the "main repo" as needed.
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. 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, but to my 
mind that is simply wrong? Starting from a point of separate repo's simply 
allows a lot easier management of everything and we can work on areas that we 
want to without having to clone the whole code base? Moving things in and out of 
the core distribution is then just a matter of adding or removing the subrepo to 
the master project.

> just my 2 cents before i get a headache from this
I had that for 6 months until I realised that I could simply ignore git and run 
everything via hg - using hggit :)

Moving to DVCS is not the problem. It's doing it in a way that works well for PHP!

-- 
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