> >
> > If I understand correctly the manual, this code won't work:
> >
> > if (!defined('__HEADER_INC__'))
> > require("./header.inc.php3");
> >
> > Marc
>
> However, this will:
>
> if (!defined('__HEADER_INC__'))
> {
> require("./header.inc.php3");
> };
>
> The only problem is that variables defined in header.inc.php3
> and not in
> the require()ing file won't be visible outside of the braces.
No. Global variables defined in header.inc.php3 *will* be visible
outside of braces if __HEADER_INC__ is defined.
I made the test and that behaviour did not change through php versions.
For more information, consult that page about variables scope in php :
http://www.php.net/manual/en/language.variables.scope.php
Note that if __HEADER_INC__ is not defined, the content of header.inc.php3
will be included but not parsed. That's why things will be as if it had not
been required.
As far as I'm concerned, I would really prefer putting the
if (!defined('__HEADER_INC__'))
directly inside header.inc.php3 as when coding in C or C++.
I find it quite a hell to always put such an if each time header.inc.php3
has to be required (and what if we change __HEADER_INC__ in HEADER_INC or
whatever?). With a single 'if' in header.inc.php3 the final result will
be exactly the same.
Hi,
http://phpmyadmin.sourceforge.net/phpMyAdmin-loic5.tar.gz
is to correct the 2 messages in lang/* that I had forgotten
to merge.
Problems pending:
- a define problem in PHP 3.0.16 (probably solved, waiting for
confirmation)
- the ob_lib.inc.php3 re-including
Apart from those problems, what is your feeling about this version?
Marc
Hi,
Ok please test
http://phpmyadmin.sourceforge.net/phpMyAdmin-loic4.tar.gz
This one should solve the problems of preceding versions, except:
- create table with no fields: This is not introduced by LV, so I entered it in Bug tracker
- file(s) included more than once: I don't have time to work on this right now.
Marc
Howdy all.
I have defined "__HEADER_INC__" in header.inc.php3 and also made the
requires that require header.inc.php3 conditional.
Also, a slight programmer note:
Anyone adding code to this project should, when requiring header.inc.php3,
only do it if !defined('__HEADER_INC___').
Jeremy
--
Jeremy Brand :: Sr. Software Engineer :: +393485323988 :: jeremy(a)nirvani.net
http://www.JeremyBrand.com/Jeremy/Brand/Jeremy_Brand.html for more
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"LINUX is obsolete" -- Andy Tanenbaum, January 29th, 1992
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Get your own Free, Private email at http://www.smackdown.com/
Maybe we should say that when a version is release candidate:
- we fork a new branch for that rc
- then *only* bug fixes are made to the rc branch
and they would have to be backported to the real branch
- when the rc seems stable enough we release it
Result:
+ allows further developement on the real branch
+ reduces backports to bug fixes found in the rc branch
- maybe bug fixes backports would be difficult to make
on a real branch that may have changed a lot
What do you think about that?
> -----Original Message-----
> From: Geert Lund - SilverSoft Productions [mailto:glund@silversoft.dk]
> Sent: Wednesday, July 25, 2001 7:55 PM
> To: phpmyadmin-devel(a)lists.sourceforge.net
> Subject: Re: [Phpmyadmin-devel] 2 versions
>
>
> > okay, i agree your arguments, but every time we made
> > the next release candidate (like 2.3.0 rc1, 2.4.0 rcX, ...)
> > the real development in cvs stops, if we have no alternative
> > cvs tree.
>
> I agree - and it makes it a hell lot more difficult to trace
> changes and
> the influence of these changes to existing code. When involving many
> deveopers spread around the world - CVS becomes very
> essential to other
> developers in the spirit of checking code with changes made by other
> developers.
>
> CVS is actually working as a developer-community and more
> important as a
> documentation of all minor/major changes - making it a lot easier to
> backtrace introduced bugs and resolving those.
>
> So my conclusion: when developers ain't sitting around in the same
> office or building - CVS is essential to successfull development and
> bug-tracing/solving and it's really worth the trouble of maintaing
> "branches" - making it possible for everyone to see changes. So it's a
> bad idea to skip CVS and everyones staring to develop new features /
> making code more efficient in their own versions - making it
> a hell lot
> more dificult to merge all those versions in the end...
>
> So let's keep the development visible to all in CVS and let it help in
> keeping the development-team together and focused on the same
> goal :-)))
>
> --
> Kind regards
> Geert Lund
>
>
> _______________________________________________
> Phpmyadmin-devel mailing list
> Phpmyadmin-devel(a)lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
>
Hi,
Ok, from now on, I ask every developer to stop writing to cvs: no new
features *and no bug correction*.
We then test Loïc's version (LV), and send patches to the devel list.
When this version is stable, someone backports the fixes and language
updates done in cvs since the fork, and this becomes a new version: LV2.
We test this, and when stable, this version goes to cvs and becomes
2.2.0rc4.
Agreed?
Marc
Hi,
the cvs version and Loic's version are forking more and more each day.
How many persons are testing Loic's version (LV)?
(You know I don't like code branching, so...)
Suggestion:
- we stop modifying cvs right now
- we fully test LV
- someone backports the changes made into cvs to LV
- someone puts LV in cvs
- we fully test cvs
- this becomes rc4
Feedback?
Marc
Testing LV + the 2 patches I sent to the list.
This query:
SELECT * FROM an2000 WHERE fromchamp like '%2000'
works ok in cvs, but becomes in LV:
SELECT * FROM `an2000` WHERE fromchamp like ' 00'
Which means this bug is back: 434405, Percent bug in delete queries
Oops, too much decoding? I will try without the patches.
Marc
