Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
Rasmus Lerdorf wrote: The other way to solve this would be to make max_input_vars PHP_INI_ALL and then just let people ini_set() their way around the limit. That's probably going to confuse people if it doesn't change the HTTP request parsing limit too, IMHO. And I'm not sure that's something we necessarily want. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
Hi! That's probably going to confuse people if it doesn't change the HTTP request parsing limit too, IMHO. And I'm not sure that's something we necessarily want. Err, how you can change it after HTTP request has already been parsed? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
On 03/14/2012 02:40 PM, Ryan McCue wrote: Rasmus Lerdorf wrote: The other way to solve this would be to make max_input_vars PHP_INI_ALL and then just let people ini_set() their way around the limit. That's probably going to confuse people if it doesn't change the HTTP request parsing limit too, IMHO. And I'm not sure that's something we necessarily want. I think that is a documentation issue. We already have plenty of confusion here because it isn't documented that parse_str() is affected by the max_input_vars setting. There is no perfect solution to this one. We need the least destabilizing fix for the inadvertent breakage we caused in 5.3. I think we were all under the impression that it was really unlikely that a default limit of 1000 input vars would cause a problem, and even in the rare case where it did, people could increase it. What we didn't take into account was that there were backend pieces affected by this frontend restriction and we didn't provide a way to decouple the two. Making max_input_vars PHP_INI_ALL is the least intrusive way to remedy this in the stable 5.3.x tree. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
Stas Malyshev wrote: Hi! That's probably going to confuse people if it doesn't change the HTTP request parsing limit too, IMHO. And I'm not sure that's something we necessarily want. Err, how you can change it after HTTP request has already been parsed? I'm not arguing that it should, I'm saying that in the INI it refers to the HTTP arguments, while in the code (via ini_set) it would not affect this. I think that could be confusing for users who don't realise the script is only loaded after parsing the request. Rasmus Lerdorf wrote: I think that is a documentation issue. We already have plenty of confusion here because it isn't documented that parse_str() is affected by the max_input_vars setting. I think that is definitely a documentation issue, but the extra argument is the way to go in terms of being the least confusing option. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem with zend_alter_ini_entry
Hi list, i'm new on the list so im sorry if this problem has been already discussed. I have an Apache module that, in translate_name hook, sets PHP ini values at runtime with zend_alter_ini_entry() (mod_php). The systems used for tests is a debian lenny, with php5.3.3 manually compiled from debian src packages. This is the piece of code: if(zend_alter_ini_entry(include_path, strlen(include_path) + 1, (void *)include,strlen(include), PHP_INI_SYSTEM, PHP_INI_STAGE_RUNTIME) != 0) ap_log_rerror(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0, r, zend_alter_ini_entry failed, include_path: %s, include); if(zend_alter_ini_entry(open_basedir, strlen(open_basedir) + 1, (void *)openbasedir, strlen(openbasedir), PHP_INI_SYSTEM, PHP_INI_STAGE_RUNTIME) != 0) ap_log_rerror(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0, r, zend_alter_ini_entry failed, open_basedir: %s, openbasedir); It works fine for both include and openbasedir (i use r-pool for these). But about 3-5% of requests i get this error on http requests: Warning: require_once(): open_basedir restriction in effect. File(/home/www-data/asdpes.it/html/wp-load.php) is not within the allowed path(s): (:/tmp/:/usr/share/php/:.:/home/www-data/evostreaming.com/html/) in /home/www-data/asdpes.it/html/wp-admin/admin.php on line 30 Has you can see in this case open_basedir refers to a wrong path asdpes.it/evostreaming.com. Plus, for some requests, i get this error in logs for open_basedir, but _never_ for includepath settings. [...] [error] [client ] zend_alter_ini_entry failed, open_basedir: /home/www-data/massimobertoldo.it/html:/tmp/:/usr/share/php/:.:/home/www-data/massimobertoldo.it/html I notice this problems since i migrated some servers from php5.2 (lenny binary) to php5.3.3. Any suggestion? -- Simone Caruso -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Small question about performance
Hello internals,
I've been involved in a discussion at the PHP Standards Group and we
recently had the following statement:
*Say you had a loop, and inside that loop you wanted to modify a param
**update the key:**
**foreach($a as $key = $val) {
** $a[$key] = someLong(functionCalls(hereThat($spanOver85Chars)));
**}**
**If this exceeded the line width, you would have to split things like
**this over a few lines, storing the val temporarily in a zval's until
**you reached your end computation. Therefore allocating more memory
**iteratively. *
I'm curious about this. Can anyone confirm it or a benchmark should be
made?
Re: [PHP-DEV] Small question about performance
On Thu, March 15, 2012 9:21 am, Klaus Silveira wrote:
Hello internals,
I've been involved in a discussion at the PHP Standards Group and we
recently had the following statement:
*Say you had a loop, and inside that loop you wanted to modify a param
**update the key:**
**foreach($a as $key = $val) {
** $a[$key] = someLong(functionCalls(hereThat($spanOver85Chars)));
**}**
**If this exceeded the line width, you would have to split things
like
**this over a few lines, storing the val temporarily in a zval's
until
**you reached your end computation. Therefore allocating more memory
**iteratively. *
I'm curious about this. Can anyone confirm it or a benchmark should be
made?
I don't see why your standard can't allow for:
$a[$key] =
someLong(
functionCalls(
hereThat(
$spanOver85Chars
) ) );
Some folks insist that the closing parens be on separate lines.
They're isomorphic to me, so I just put them on one line.
So long as the count matches and they line up in reverse order,
indented properly, it's all good.
But then, I cut my teeth on Lisp, where a zillion parens to close off
almost anything is the norm. :-)
PS
If you want a benchmark for how much 3 or 4 temporary zvals takes,
knock yourself out.
Also consider trying this in a second benchmark:
//don't create / destroy zvals in the loop, hopefully
$someLong = '';
$functionCalls = '';
$hereThat = '';
foreach ($a as $key = $value){
...
}
PPS
I'm assuming $a is not within the Coding Standard :-)
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small question about performance
On Thu, Mar 15, 2012 at 3:21 PM, Klaus Silveira klaussilve...@php.net wrote:
Hello internals,
I've been involved in a discussion at the PHP Standards Group and we
recently had the following statement:
*Say you had a loop, and inside that loop you wanted to modify a param
**update the key:**
**foreach($a as $key = $val) {
** $a[$key] = someLong(functionCalls(hereThat($spanOver85Chars)));
**}**
**If this exceeded the line width, you would have to split things like
**this over a few lines, storing the val temporarily in a zval's until
**you reached your end computation. Therefore allocating more memory
**iteratively. *
If I am understanding the text correctly it is saying that
$f1 = f1();
$f2 = f2($f1);
$f3 = f3($f2);
is using more memory than
$f3 = f3(f2(f1()));
For me this doesn't make any sense. In the latter case PHP will also
create temporary variables to store the return values. There should be
no difference in memory consumption.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
On Wed, March 14, 2012 12:09 pm, Ferenc Kovacs wrote: On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadl...@gmail.comwrote: On 23 July 2011 23:29, Ferenc Kovacs tyr...@gmail.com wrote: I would propose that the defaul values(PHP_INI_ENTRY_*) and the php.ini-production should be keep in sync as much as possible. I'm +1 if only for the fact that I wouldn't have to research what's different and re-write my (stupid) RFC about E_ALL being the default in PHP_INI_ENTRY* ... I have always presumed that PHP_INI_ENTRY* matched at least one of the two php.ini-* files shipped, actually. Guess that was naive, but it USED to be that way, back in the day, as far as I know... So in terms of expected behavior this can almost be considered a break in BC... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let parse_str() parse more than max_input_vars args
On Thu, March 15, 2012 5:01 am, Ryan McCue wrote: I'm not arguing that it should, I'm saying that in the INI it refers to the HTTP arguments, while in the code (via ini_set) it would not affect this. I think that could be confusing for users who don't realise the script is only loaded after parsing the request. If they don't know it by the time they need parse_str, it's time for them to learn it... :-) Not saying it won't cause confusion: But they have to make some effort to figure out how PHP works. Maybe a link in the error message to something that documents the workflow clearly enough that they get it just by clicking on the link and reading? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small question about performance
2012/3/15 Nikita Popov nikita@googlemail.com:
If I am understanding the text correctly it is saying that
$f1 = f1();
$f2 = f2($f1);
$f3 = f3($f2);
is using more memory than
$f3 = f3(f2(f1()));
For me this doesn't make any sense. In the latter case PHP will also
create temporary variables to store the return values. There should be
no difference in memory consumption.
It does make sense to me.
In the first case, when calling f3(), $f1 is still referenced.
In the second case, when calling f3(), the result of f2() is
referenced, but there is no more active reference to the result of
f1().
Regarding the original problem:
foreach($a as $key = $val) {
$a[$key] = someLong(functionCalls(hereThat($spanOver85Chars)));
}
Sounds easier to split over lines without temporary zvals:
foreach($a as $key = $val) {
$a[$key] = someLong(
functionCalls(
hereThat(
$spanOver85Chars
)
)
);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small question about performance
Just to elaborate on what Patrick said, in the first case the variables are
temporary, where in the second they persist even after you finish your
loop. So even after the foreach is finished, the $f1, $f2, and $f3
variables are still storing data- even though it is no longer needed.
In order to free up the memory allocated to these variables you'd have to
unset them after they're used in the loop, or after the loop has finished.
- Mike
On Thu, Mar 15, 2012 at 11:22 AM, Patrick ALLAERT patrickalla...@php.netwrote:
2012/3/15 Nikita Popov nikita@googlemail.com:
If I am understanding the text correctly it is saying that
$f1 = f1();
$f2 = f2($f1);
$f3 = f3($f2);
is using more memory than
$f3 = f3(f2(f1()));
For me this doesn't make any sense. In the latter case PHP will also
create temporary variables to store the return values. There should be
no difference in memory consumption.
It does make sense to me.
In the first case, when calling f3(), $f1 is still referenced.
In the second case, when calling f3(), the result of f2() is
referenced, but there is no more active reference to the result of
f1().
Regarding the original problem:
foreach($a as $key = $val) {
$a[$key] = someLong(functionCalls(hereThat($spanOver85Chars)));
}
Sounds easier to split over lines without temporary zvals:
foreach($a as $key = $val) {
$a[$key] = someLong(
functionCalls(
hereThat(
$spanOver85Chars
)
)
);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
---
My command is this: Love each other as I
have loved you. John 15:12
---
Re: [PHP-DEV] Small question about performance
Hi! If I am understanding the text correctly it is saying that $f1 = f1(); $f2 = f2($f1); $f3 = f3($f2); is using more memory than $f3 = f3(f2(f1())); Short answer: it doesn't matter, use either as you wish. Long answer: Technically, the former also uses hash buckets to bind values to the symbol table, so it can use more memory (and if it so happens that using these variables makes symbol table go over hashtable threshold, hashtable internal storage size will be increased), so it will consume marginally more memory. But the difference is completely negligible. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small question about performance
On Thu, Mar 15, 2012 at 5:22 PM, Patrick ALLAERT patrickalla...@php.net wrote: 2012/3/15 Nikita Popov nikita@googlemail.com: If I am understanding the text correctly it is saying that $f1 = f1(); $f2 = f2($f1); $f3 = f3($f2); is using more memory than $f3 = f3(f2(f1())); For me this doesn't make any sense. In the latter case PHP will also create temporary variables to store the return values. There should be no difference in memory consumption. It does make sense to me. In the first case, when calling f3(), $f1 is still referenced. In the second case, when calling f3(), the result of f2() is referenced, but there is no more active reference to the result of f1(). I don't really know when PHP frees temporary variables, but my guess was that they are freed when the scope is left. If that is not true, then forget whatever I said. But if it is true, then there is no inherent difference between the two version. The only difference is that explicit $variables would need an entry in the active symbol table, which is pretty much negligible. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small question about performance
On Thu, Mar 15, 2012 at 4:54 PM, Nikita Popov nikita@googlemail.com wrote: On Thu, Mar 15, 2012 at 5:22 PM, Patrick ALLAERT patrickalla...@php.net wrote: 2012/3/15 Nikita Popov nikita@googlemail.com: If I am understanding the text correctly it is saying that $f1 = f1(); $f2 = f2($f1); $f3 = f3($f2); is using more memory than $f3 = f3(f2(f1())); For me this doesn't make any sense. In the latter case PHP will also create temporary variables to store the return values. There should be no difference in memory consumption. It does make sense to me. In the first case, when calling f3(), $f1 is still referenced. In the second case, when calling f3(), the result of f2() is referenced, but there is no more active reference to the result of f1(). I don't really know when PHP frees temporary variables, but my guess was that they are freed when the scope is left. Each variable has a refcount, then that hits 0 it can be freed up. If that is not true, then forget whatever I said. But if it is true, then there is no inherent difference between the two version. The only difference is that explicit $variables would need an entry in the active symbol table, which is pretty much negligible. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small question about performance
On Thu, Mar 15, 2012 at 5:39 PM, Paul Dragoonis dragoo...@gmail.com wrote: On Thu, Mar 15, 2012 at 4:54 PM, Nikita Popov nikita@googlemail.com wrote: On Thu, Mar 15, 2012 at 5:22 PM, Patrick ALLAERT patrickalla...@php.net wrote: 2012/3/15 Nikita Popov nikita@googlemail.com: If I am understanding the text correctly it is saying that $f1 = f1(); $f2 = f2($f1); $f3 = f3($f2); is using more memory than $f3 = f3(f2(f1())); For me this doesn't make any sense. In the latter case PHP will also create temporary variables to store the return values. There should be no difference in memory consumption. It does make sense to me. In the first case, when calling f3(), $f1 is still referenced. In the second case, when calling f3(), the result of f2() is referenced, but there is no more active reference to the result of f1(). I don't really know when PHP frees temporary variables, but my guess was that they are freed when the scope is left. Each variable has a refcount, then that hits 0 it can be freed up. To add to that. A zval will have a refcount, so if you do $a = someFunc(); then $a will have a refcount. If you do something like $a = someFunc(anotherFunc(moreFunc())), the return values of anotherFunc() and moreFunc() will be temp stored, but they will _not_ have a refcount because they never got assigned into a zval like $a. Hope that made sense. If that is not true, then forget whatever I said. But if it is true, then there is no inherent difference between the two version. The only difference is that explicit $variables would need an entry in the active symbol table, which is pretty much negligible. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Q: ZEND_HANDLE_STREAM and wincache extension on PHP 5.4
PHP Internals folks-- My name is Eric Stenson, and I'm a developer at Microsoft working on IIS. I've been given the task of upgrading our php_wincache extension to work on PHP5.4, and I've run into a problem. The problem I'm running into is the php_cgi!main() on PHP5.4 has changed behavior. The php_cgi!main() function is seeing us return a ZEND_HANDLE_STREAM, and it's assuming that the zend_file_handle.handle.stream.handle (void *) is a (php_stream*), when in fact it's php_wincache's (fcache_handle *). It then attempts to access the php_stream.ops (a v-table-ish struct), which is not in the fcache_handle, and it jumps off into an invalid address and promptly AV's. I'm trying to understand why our php_wincache!fcache_useval() thinks it's okay to set zend_file_handle.handle.stream.handle to (fcache_handle *). I'm having trouble understanding what the responsibilities are of a PHP extension that extends the file system as php_wincache does. Could you point me at any developer documents for PHP extension developers that explains what php_wincache *should* be doing? I'm very much a novice at PHP code, or writing a PHP extension, so I feel like I'm flailing around without understanding what PHP extensions are supposed to do. Any pointers, guidance, and architecture advice would be massively helpful! Thank you! --E. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Small question about performance
Am 15.03.2012 18:41, schrieb Paul Dragoonis:
I don't really know when PHP frees temporary variables, but my guess
was that they are freed when the scope is left.
Each variable has a refcount, then that hits 0 it can be freed up.
To add to that. A zval will have a refcount, so if you do $a =
someFunc(); then $a will have a refcount.
If you do something like $a = someFunc(anotherFunc(moreFunc())), the
return values of anotherFunc() and moreFunc() will be temp stored, but
they will _not_ have a refcount because they never got assigned into a
zval like $a.
to make sure i understand this really
function myfunc()
{
$b = internal_function_with_hughe_return_value();
return false;
}
$b is freed after the function has finished
if not i should write a lot of unset() what
is not possible if you have return $b
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Small question about performance
The $b on this example would be freed as it is in the function's scope, and
not the global scope. The exception to this would be a static variable
within a function, which would persist for future use within the function.
Class properties on the other hand will persist until the object is
destructed, or until they are unset.
So for your example,
function test() {
$b = 'apple';
return $b;
}
You would not need to unset $b as it resides temporarily within the
function, and does not persist outside of the function.
- Mike
On Thu, Mar 15, 2012 at 1:58 PM, Reindl Harald h.rei...@thelounge.netwrote:
Am 15.03.2012 18:41, schrieb Paul Dragoonis:
I don't really know when PHP frees temporary variables, but my guess
was that they are freed when the scope is left.
Each variable has a refcount, then that hits 0 it can be freed up.
To add to that. A zval will have a refcount, so if you do $a =
someFunc(); then $a will have a refcount.
If you do something like $a = someFunc(anotherFunc(moreFunc())), the
return values of anotherFunc() and moreFunc() will be temp stored, but
they will _not_ have a refcount because they never got assigned into a
zval like $a.
to make sure i understand this really
function myfunc()
{
$b = internal_function_with_hughe_return_value();
return false;
}
$b is freed after the function has finished
if not i should write a lot of unset() what
is not possible if you have return $b
--
---
My command is this: Love each other as I
have loved you. John 15:12
---
Re: [PHP-DEV] Small question about performance
thanks
exactly what i assumed, but better to be sure instead
wasting somewhere ressources without need :-)
Am 15.03.2012 20:10, schrieb Michael Stowe:
The $b on this example would be freed as it is in the function's scope, and
not the global scope. The exception to this would be a static variable
within a function, which would persist for future use within the function.
Class properties on the other hand will persist until the object is
destructed, or until they are unset.
So for your example,
function test() {
$b = 'apple';
return $b;
}
You would not need to unset $b as it resides temporarily within the
function, and does not persist outside of the function.
signature.asc
Description: OpenPGP digital signature
[PHP-DEV] Git Migration delayed until Monday
Hi, I am sorry. I was ill in the last days and we some implementations were just finished. We have to delay the migration till Sunday 15. I am working workflow FAQ atm. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q: ZEND_HANDLE_STREAM and wincache extension on PHP 5.4
On Thu, 15 Mar 2012 19:56:11 +0100, Eric Stenson erics...@microsoft.com wrote: The problem I'm running into is the php_cgi!main() on PHP5.4 has changed behavior. The php_cgi!main() function is seeing us return a ZEND_HANDLE_STREAM, and it's assuming that the zend_file_handle.handle.stream.handle (void *) is a (php_stream*), when in fact it's php_wincache's (fcache_handle *). It then attempts to access the php_stream.ops (a v-table-ish struct), which is not in the fcache_handle, and it jumps off into an invalid address and promptly AV's. [...] I think you should contact Dmitry, as he was the one that committed r301058. That code looks very strange. It seems to want to break the abstraction of zend_stream and assume that handle stores a php_stream (to use e.g. zend_stream_getc instead of php_stream_getc). But I don't think the assumption done to break the abstraction is correct. For instance, see http://lxr.php.net/opengrok/xref/PHP_TRUNK/ext/phar/phar.c#3364 which has: file_handle-handle.stream.handle = phar; and *phar is of type phar_archive_data, which is not a php_stream (or an augmentation thereof). -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Git Migration delayed until Sunday
On 2012-03-15, David Soria Parra d...@php.net wrote: Hi, I am sorry. I was ill in the last days and we some implementations were just finished. We have to delay the migration till Sunday 15. I am working workflow FAQ atm. oh god, that's a mess. It's Sunday 18. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git Migration: Status Update
Lester Caine les...@lsces.co.uk writes: jeremiah.do...@gmail.com wrote: I hope that clarifies things a bit. It definitely doesn't make grokking things a whole lot easier, and it is certainly *possible* to follow a very svnish workflow using git (and may sometimes make sense to, although I am struggling to thing of such a time). I've been using Hg myself for the 'DVCS' style of working. This allows me to publish my own ports of things which others can follow, but from which I can push things back to the original project as required. I'm still not convinced that the 'production' branches such as PHP5.3 can be run without some element of management, although of cause a release will still be packaged as a tarball set and then frozen. On Hg I just pull a particular tarball ... such as PHP5.3.10 ... as I require it direct from the repo but some of the projects I am working with have now lost the 'master' codebase simply because groups of developers are now doing their own thing. The overall flexibility of DVCS still needs a mindset of maintaining a code base that follows the master route plan? Which may well be a more 'svnish' way of working when testing and committing production ready code? I use Hg at work, and while it's a pretty fine DVCS, it's more in line with SVN's mindset than git's in parts. Namely, Hg focuses, afaict, on making it easy to move the commit history forward in time by abstracting over the manipulation of the DAG. Git focuses on manipulation of the DAG -- the line between locally-visible and remotely-visible stuff is more blurry in Hg than in git, and it feels like you're using the tool in unintended ways when you clarify that line in ways Hg doesn't expect. That's not necessarily a bad thing or whatnot, just a thing. The question I think that needs to be asked is 'should experimental development branches exist in the master code base?' all very easy to do with DVCS, but is it practical. Does it not make sense to clone the experimental work from another source, and keep the main codebase tidy with just proven pushes that follow the production path. There is nothing actually stopping someone producing their own private branch and sharing that while it is being developed, just pushing the results back to the relevant master branch when development work has been completed? If the experimental branches are long(er)-lived and worked on or of interest to people who'd be checking out master, sure. There's definitely a balancing act -- you don't want 500 experimental branches laying around yer main repo, but that probably won't happen, in no small part because when you merge the experimental branch in to a master release you can just delete it. The commits won't be lost, but it won't be showing up in `git branch -ar` or whatnot -- the branch is just a pointer to a node in the DAG to git. There isn't the concept of permanent always-stick-around-branch like in Hg, unless you decide to make it so. For a good example of hey keep these relevant branches around on master, take a look at https://github.com/symfony/symfony . There's a few branches sitting around on their main repo at any point in time -- the master, development branch, maybe some other feature, whatever. Like you mention, people interested in a particular niche of the framework are pulling from branches on each others git repositories, and there are a ridiculous amount of branches in the ecosystem, see https://github.com/symfony/symfony/network . For a bad example, look at the git mirrors of emacs (at least the last time I looked at them). Yeah, there's reasons for it there, but the point is that having too many of them produces noise. Which is true. I don't think there are any hard and fast rules here, but at least git makes it easy to change things up if they lean too far in either direction. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
