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 ..
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.
just my 2 cents before i get a headache from this
Regards,
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
