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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
