From piotr.prz@gmail.com Wed Jul 13 22:28:29 2011 From: Piotr Przybylski To: developers@phpmyadmin.net Subject: [Phpmyadmin-devel] XML export Date: Thu, 14 Jul 2011 00:28:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5124164271185434154==" --===============5124164271185434154== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, Is XML export used at all? It was missing data escaping in many places, and structure (table, function, ...) export was just broken. I fixed it a bit, but there are still some problems that remain: - escaping of table/db names and data in other encodings than ISO-8859-1 - it uses SHOW CREATE TABLE without any required fixes File format itself is interesting. I don't expect XML Schema for it to exist, but at least namespace usage should be consistent. I think fixing this and rewriting output format to be more consistent should appear on Tasks for junior developers. And maybe extending it to output data in more concise format, eg.: value ... ...
-- Regards, Piotr Przybylski --===============5124164271185434154==-- From marc@infomarc.info Thu Jul 14 12:50:13 2011 From: Marc Delisle To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Thu, 14 Jul 2011 08:51:32 -0400 Message-ID: <4E1EE654.2000208@infomarc.info> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3498481938250295189==" --===============3498481938250295189== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Le 2011-07-13 18:28, Piotr Przybylski a écrit : > Hi, > > Is XML export used at all? It was missing data escaping in many > places, and structure (table, function, ...) export was just broken. I > fixed it a bit, but there are still some problems that remain: > - escaping of table/db names and data in other encodings than ISO-8859-1 > - it uses SHOW CREATE TABLE without any required fixes > > File format itself is interesting. I don't expect XML Schema for it to > exist, but at least namespace usage should be consistent. > > I think fixing this and rewriting output format to be more consistent > should appear on Tasks for junior developers. And maybe extending it > to output data in more concise format, eg.: > > > value > ... > > ... >
> Piotr, XML export is probably used, how can we know? In your testing, was it just a problem in master or also in 3.4.x? -- Marc Delisle http://infomarc.info --===============3498481938250295189==-- From piotr.prz@gmail.com Thu Jul 14 13:24:17 2011 From: Piotr Przybylski To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Thu, 14 Jul 2011 15:24:09 +0200 Message-ID: In-Reply-To: <4E1EE654.2000208@infomarc.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7536753705604503755==" --===============7536753705604503755== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 2011/7/14 Marc Delisle : > Le 2011-07-13 18:28, Piotr Przybylski a écrit : >> Hi, >> >> Is XML export used at all? It was missing data escaping in many >> places, and structure (table, function, ...) export was just broken. I >> fixed it a bit, but there are still some problems that remain: >> - escaping of table/db names and data in other encodings than ISO-8859-1 >> - it uses SHOW CREATE TABLE without any required fixes >> >> File format itself is interesting. I don't expect XML Schema for it to >> exist, but at least namespace usage should be consistent. >> >> I think fixing this and rewriting output format to be more consistent >> should appear on Tasks for junior developers. And maybe extending it >> to output data in more concise format, eg.: >> >> >> value >> ... >> >> ... >>
>> > Piotr, > XML export is probably used, how can we know? Maybe nobody needs DDL in it or we have too few people using it to report bugs :) > In your testing, was it just a problem in master or also in 3.4.x? > Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to export table `evil'"*/>` with all options selected. You will get only data (no structure) and invalid XML Another broken plugin is CodeGen, it ignores it's format setting and always outputs C# code (I will push a bugfix to master later today). -- Piotr Przybylski --===============7536753705604503755==-- From marc@infomarc.info Thu Jul 14 13:29:51 2011 From: Marc Delisle To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Thu, 14 Jul 2011 09:31:09 -0400 Message-ID: <4E1EEF9D.8050207@infomarc.info> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2003146655353599373==" --===============2003146655353599373== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Le 2011-07-14 09:24, Piotr Przybylski a écrit : > 2011/7/14 Marc Delisle: >> Le 2011-07-13 18:28, Piotr Przybylski a écrit : >>> Hi, >>> >>> Is XML export used at all? It was missing data escaping in many >>> places, and structure (table, function, ...) export was just broken. I >>> fixed it a bit, but there are still some problems that remain: >>> - escaping of table/db names and data in other encodings than ISO-8859-1 >>> - it uses SHOW CREATE TABLE without any required fixes >>> >>> File format itself is interesting. I don't expect XML Schema for it to >>> exist, but at least namespace usage should be consistent. >>> >>> I think fixing this and rewriting output format to be more consistent >>> should appear on Tasks for junior developers. And maybe extending it >>> to output data in more concise format, eg.: >>> >>> >>> value >>> ... >>> >>> ... >>>
>>> >> Piotr, >> XML export is probably used, how can we know? > > Maybe nobody needs DDL in it or we have too few people using it to > report bugs :) > >> In your testing, was it just a problem in master or also in 3.4.x? >> > > Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to export > table `evil'"*/>` with all options selected. You will get only data > (no structure) and invalid XML Can you backport your fixes to QA_3_4? > > Another broken plugin is CodeGen, it ignores it's format setting and > always outputs C# code (I will push a bugfix to master later today). > -- Marc Delisle http://infomarc.info --===============2003146655353599373==-- From piotr.prz@gmail.com Thu Jul 14 19:43:40 2011 From: Piotr Przybylski To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Thu, 14 Jul 2011 21:43:30 +0200 Message-ID: In-Reply-To: <4E1EEF9D.8050207@infomarc.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3901804670876519415==" --===============3901804670876519415== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 2011/7/14 Marc Delisle : > Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit : >> 2011/7/14 Marc Delisle: >>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit : >>>> Hi, >>>> >>>> Is XML export used at all? It was missing data escaping in many >>>> places, and structure (table, function, ...) export was just broken. I >>>> fixed it a bit, but there are still some problems that remain: >>>> - escaping of table/db names and data in other encodings than ISO-8859-1 >>>> - it uses SHOW CREATE TABLE without any required fixes >>>> >>>> File format itself is interesting. I don't expect XML Schema for it to >>>> exist, but at least namespace usage should be consistent. >>>> >>>> I think fixing this and rewriting output format to be more consistent >>>> should appear on Tasks for junior developers. And maybe extending it >>>> to output data in more concise format, eg.: >>>> >>>> >>>> value >>>> ... >>>> >>>> ... >>>>
>>>> >>> Piotr, >>> XML export is probably used, how can we know? >> >> Maybe nobody needs DDL in it or we have too few people using it to >> report bugs :) >> >>> In your testing, was it just a problem in master or also in 3.4.x? >>> >> >> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to export >> table `evil'"*/>` with all options selected. You will get only data >> (no structure) and invalid XML > > Can you backport your fixes to QA_3_4? > Yes. Just to be sure I don't break anything - what's the proper way of doing = it? 1. Create a local branch traacking origin/QA_3_4 2. cherry-pick my commits to master 3. push ? --=20 Piotr Przybylski --===============3901804670876519415==-- From marc@infomarc.info Thu Jul 14 20:56:29 2011 From: Marc Delisle To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Thu, 14 Jul 2011 16:57:47 -0400 Message-ID: <4E1F584B.5020009@infomarc.info> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0959001191803588777==" --===============0959001191803588777== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Le 2011-07-14 15:43, Piotr Przybylski a =C3=A9crit : > 2011/7/14 Marc Delisle: >> Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit : >>> 2011/7/14 Marc Delisle: >>>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit : >>>>> Hi, >>>>> >>>>> Is XML export used at all? It was missing data escaping in many >>>>> places, and structure (table, function, ...) export was just broken. I >>>>> fixed it a bit, but there are still some problems that remain: >>>>> - escaping of table/db names and data in other encodings than ISO-8859-1 >>>>> - it uses SHOW CREATE TABLE without any required fixes >>>>> >>>>> File format itself is interesting. I don't expect XML Schema for it to >>>>> exist, but at least namespace usage should be consistent. >>>>> >>>>> I think fixing this and rewriting output format to be more consistent >>>>> should appear on Tasks for junior developers. And maybe extending it >>>>> to output data in more concise format, eg.: >>>>> >>>>> >>>>> value >>>>> ... >>>>> >>>>> ... >>>>>
>>>>> >>>> Piotr, >>>> XML export is probably used, how can we know? >>> >>> Maybe nobody needs DDL in it or we have too few people using it to >>> report bugs :) >>> >>>> In your testing, was it just a problem in master or also in 3.4.x? >>>> >>> >>> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to export >>> table `evil'"*/>` with all options selected. You will get only data >>> (no structure) and invalid XML >> >> Can you backport your fixes to QA_3_4? >> > > Yes. Just to be sure I don't break anything - what's the proper way of doin= g it? > 1. Create a local branch traacking origin/QA_3_4 > 2. cherry-pick my commits to master > 3. push > ? > This should work. Usually you should have started with QA_3_4, like=20 explained on http://wiki.phpmyadmin.net/pma/Git#Committing_fixes_to_several_branches. The big mistake to avoid is merging master to QA_3_4! --=20 Marc Delisle http://infomarc.info --===============0959001191803588777==-- From piotr.prz@gmail.com Thu Jul 14 21:59:40 2011 From: Piotr Przybylski To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Thu, 14 Jul 2011 23:59:30 +0200 Message-ID: In-Reply-To: <4E1F584B.5020009@infomarc.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2157769749845228724==" --===============2157769749845228724== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 2011/7/14 Marc Delisle : > Le 2011-07-14 15:43, Piotr Przybylski a =C3=A9crit : >> 2011/7/14 Marc Delisle: >>> Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit : >>>> 2011/7/14 Marc Delisle: >>>>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit : >>>>>> Hi, >>>>>> >>>>>> Is XML export used at all? It was missing data escaping in many >>>>>> places, and structure (table, function, ...) export was just broken. I >>>>>> fixed it a bit, but there are still some problems that remain: >>>>>> - escaping of table/db names and data in other encodings than ISO-8859= -1 >>>>>> - it uses SHOW CREATE TABLE without any required fixes >>>>>> >>>>>> File format itself is interesting. I don't expect XML Schema for it to >>>>>> exist, but at least namespace usage should be consistent. >>>>>> >>>>>> I think fixing this and rewriting output format to be more consistent >>>>>> should appear on Tasks for junior developers. And maybe extending it >>>>>> to output data in more concise format, eg.: >>>>>> >>>>>> >>>>>> value >>>>>> ... >>>>>> >>>>>> ... >>>>>>
>>>>>> >>>>> Piotr, >>>>> XML export is probably used, how can we know? >>>> >>>> Maybe nobody needs DDL in it or we have too few people using it to >>>> report bugs :) >>>> >>>>> In your testing, was it just a problem in master or also in 3.4.x? >>>>> >>>> >>>> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to export >>>> table `evil'"*/>` with all options selected. You will get only data >>>> (no structure) and invalid XML >>> >>> Can you backport your fixes to QA_3_4? >>> >> >> Yes. Just to be sure I don't break anything - what's the proper way of doi= ng it? >> 1. Create a local branch traacking origin/QA_3_4 >> 2. cherry-pick my commits to master >> 3. push >> ? >> > > This should work. Thanks. > Usually you should have started with QA_3_4, like explained on > http://wiki.phpmyadmin.net/pma/Git#Committing_fixes_to_several_branches. Too late now, I had to suffer from all these merge conflicts :) > The big mistake to avoid is merging master to QA_3_4! And this one would make an interesting merge conflict :D --=20 Piotr Przybylski --===============2157769749845228724==-- From rouslan@placella.com Fri Jul 15 17:20:41 2011 From: Rouslan Placella To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Fri, 15 Jul 2011 18:20:31 +0100 Message-ID: <1310750431.2252.39.camel@roccivic-pc> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6458035674900520064==" --===============6458035674900520064== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote: > 2011/7/14 Marc Delisle : > > Le 2011-07-14 15:43, Piotr Przybylski a =C3=A9crit : > >> 2011/7/14 Marc Delisle: > >>> Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit : > >>>> 2011/7/14 Marc Delisle: > >>>>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit : > >>>>>> Hi, > >>>>>> > >>>>>> Is XML export used at all? It was missing data escaping in many > >>>>>> places, and structure (table, function, ...) export was just broken.= I > >>>>>> fixed it a bit, but there are still some problems that remain: > >>>>>> - escaping of table/db names and data in other encodings than ISO-88= 59-1 > >>>>>> - it uses SHOW CREATE TABLE without any required fixes > >>>>>> > >>>>>> File format itself is interesting. I don't expect XML Schema for it = to > >>>>>> exist, but at least namespace usage should be consistent. > >>>>>> > >>>>>> I think fixing this and rewriting output format to be more consistent > >>>>>> should appear on Tasks for junior developers. And maybe extending it > >>>>>> to output data in more concise format, eg.: > >>>>>> > >>>>>> > >>>>>> value > >>>>>> ... > >>>>>> > >>>>>> ... > >>>>>>
> >>>>>> > >>>>> Piotr, > >>>>> XML export is probably used, how can we know? > >>>> > >>>> Maybe nobody needs DDL in it or we have too few people using it to > >>>> report bugs :) > >>>> > >>>>> In your testing, was it just a problem in master or also in 3.4.x? > >>>>> > >>>> > >>>> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to export > >>>> table `evil'"*/>` with all options selected. You will get only data > >>>> (no structure) and invalid XML > >>> > >>> Can you backport your fixes to QA_3_4? > >>> > >> > >> Yes. Just to be sure I don't break anything - what's the proper way of d= oing it? > >> 1. Create a local branch traacking origin/QA_3_4 > >> 2. cherry-pick my commits to master > >> 3. push > >> ? > >> > > > > This should work. >=20 > Thanks. > > Usually you should have started with QA_3_4, like explained on > > http://wiki.phpmyadmin.net/pma/Git#Committing_fixes_to_several_branches. >=20 > Too late now, I had to suffer from all these merge conflicts :) >=20 > > The big mistake to avoid is merging master to QA_3_4! >=20 > And this one would make an interesting merge conflict :D You forgot to merge QA_3_4 back into master after applying the fixes, which I guess you didn't actually cherry-pick due to the differences in whitespace distribution, so it left some interesting conflicts for the next person merging QA_3_4 into master... So in your above list, #3 should have been 'git checkout master; git merge QA_3_4' and #4 'git push {remote_addess} master QA_3_4' Rouslan --===============6458035674900520064==-- From piotr.prz@gmail.com Fri Jul 15 18:00:47 2011 From: Piotr Przybylski To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Fri, 15 Jul 2011 20:00:37 +0200 Message-ID: In-Reply-To: <1310750431.2252.39.camel@roccivic-pc> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3796814663005981729==" --===============3796814663005981729== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 2011/7/15 Rouslan Placella : > On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote: >> 2011/7/14 Marc Delisle : >> > Le 2011-07-14 15:43, Piotr Przybylski a =C3=A9crit : >> >> 2011/7/14 Marc Delisle: >> >>> Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit : >> >>>> 2011/7/14 Marc Delisle: >> >>>>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit : >> >>>>>> Hi, >> >>>>>> >> >>>>>> Is XML export used at all? It was missing data escaping in many >> >>>>>> places, and structure (table, function, ...) export was just broken= . I >> >>>>>> fixed it a bit, but there are still some problems that remain: >> >>>>>> - escaping of table/db names and data in other encodings than ISO-8= 859-1 >> >>>>>> - it uses SHOW CREATE TABLE without any required fixes >> >>>>>> >> >>>>>> File format itself is interesting. I don't expect XML Schema for it= to >> >>>>>> exist, but at least namespace usage should be consistent. >> >>>>>> >> >>>>>> I think fixing this and rewriting output format to be more consiste= nt >> >>>>>> should appear on Tasks for junior developers. And maybe extending it >> >>>>>> to output data in more concise format, eg.: >> >>>>>> >> >>>>>> >> >>>>>> value >> >>>>>> ... >> >>>>>> >> >>>>>> ... >> >>>>>>
>> >>>>>> >> >>>>> Piotr, >> >>>>> XML export is probably used, how can we know? >> >>>> >> >>>> Maybe nobody needs DDL in it or we have too few people using it to >> >>>> report bugs :) >> >>>> >> >>>>> In your testing, was it just a problem in master or also in 3.4.x? >> >>>>> >> >>>> >> >>>> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to export >> >>>> table `evil'"*/>` with all options selected. You will get only data >> >>>> (no structure) and invalid XML >> >>> >> >>> Can you backport your fixes to QA_3_4? >> >>> >> >> >> >> Yes. Just to be sure I don't break anything - what's the proper way of = doing it? >> >> 1. Create a local branch traacking origin/QA_3_4 >> >> 2. cherry-pick my commits to master >> >> 3. push >> >> ? >> >> >> > >> > This should work. >> >> Thanks. >> > Usually you should have started with QA_3_4, like explained on >> > http://wiki.phpmyadmin.net/pma/Git#Committing_fixes_to_several_branches. >> >> Too late now, I had to suffer from all these merge conflicts :) >> >> > The big mistake to avoid is merging master to QA_3_4! >> >> And this one would make an interesting merge conflict :D > > You forgot to merge QA_3_4 back into master after applying the fixes, > which I guess you didn't actually cherry-pick due to the differences in > whitespace distribution, so it left some interesting conflicts for the > next person merging QA_3_4 into master... Oops, sorry. Fortunately the correct way to resolve them was to use the file from master. --=20 Piotr Przybylski --===============3796814663005981729==-- From rouslan@placella.com Fri Jul 15 18:05:28 2011 From: Rouslan Placella To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Fri, 15 Jul 2011 19:05:16 +0100 Message-ID: <1310753116.2252.49.camel@roccivic-pc> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3651985377086813981==" --===============3651985377086813981== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 2011-07-15 at 20:00 +0200, Piotr Przybylski wrote: > 2011/7/15 Rouslan Placella : > > On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote: > >> 2011/7/14 Marc Delisle : > >> > Le 2011-07-14 15:43, Piotr Przybylski a =C3=A9crit : > >> >> 2011/7/14 Marc Delisle: > >> >>> Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit : > >> >>>> 2011/7/14 Marc Delisle: > >> >>>>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit : > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>> Is XML export used at all? It was missing data escaping in many > >> >>>>>> places, and structure (table, function, ...) export was just brok= en. I > >> >>>>>> fixed it a bit, but there are still some problems that remain: > >> >>>>>> - escaping of table/db names and data in other encodings than ISO= -8859-1 > >> >>>>>> - it uses SHOW CREATE TABLE without any required fixes > >> >>>>>> > >> >>>>>> File format itself is interesting. I don't expect XML Schema for = it to > >> >>>>>> exist, but at least namespace usage should be consistent. > >> >>>>>> > >> >>>>>> I think fixing this and rewriting output format to be more consis= tent > >> >>>>>> should appear on Tasks for junior developers. And maybe extending= it > >> >>>>>> to output data in more concise format, eg.: > >> >>>>>> > >> >>>>>> > >> >>>>>> value > >> >>>>>> ... > >> >>>>>> > >> >>>>>> ... > >> >>>>>>
> >> >>>>>> > >> >>>>> Piotr, > >> >>>>> XML export is probably used, how can we know? > >> >>>> > >> >>>> Maybe nobody needs DDL in it or we have too few people using it to > >> >>>> report bugs :) > >> >>>> > >> >>>>> In your testing, was it just a problem in master or also in 3.4.x? > >> >>>>> > >> >>>> > >> >>>> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to export > >> >>>> table `evil'"*/>` with all options selected. You will get only data > >> >>>> (no structure) and invalid XML > >> >>> > >> >>> Can you backport your fixes to QA_3_4? > >> >>> > >> >> > >> >> Yes. Just to be sure I don't break anything - what's the proper way o= f doing it? > >> >> 1. Create a local branch traacking origin/QA_3_4 > >> >> 2. cherry-pick my commits to master > >> >> 3. push > >> >> ? > >> >> > >> > > >> > This should work. > >> > >> Thanks. > >> > Usually you should have started with QA_3_4, like explained on > >> > http://wiki.phpmyadmin.net/pma/Git#Committing_fixes_to_several_branche= s. > >> > >> Too late now, I had to suffer from all these merge conflicts :) > >> > >> > The big mistake to avoid is merging master to QA_3_4! > >> > >> And this one would make an interesting merge conflict :D > > > > You forgot to merge QA_3_4 back into master after applying the fixes, > > which I guess you didn't actually cherry-pick due to the differences in > > whitespace distribution, so it left some interesting conflicts for the > > next person merging QA_3_4 into master... >=20 > Oops, sorry. Fortunately the correct way to resolve them was to use > the file from master. Then oops me too, because during the merge I used the hunks of code from QA_3_4 when resolving conflicts. It made sense to me at the time to keep the code from the two branches as similar to each other as possible... Rouslan --===============3651985377086813981==-- From marc@infomarc.info Fri Jul 15 18:12:17 2011 From: Marc Delisle To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] branches Date: Fri, 15 Jul 2011 14:12:16 -0400 Message-ID: <4E208300.6070800@infomarc.info> In-Reply-To: <1310753116.2252.49.camel@roccivic-pc> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2242103879546077168==" --===============2242103879546077168== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Le 2011-07-15 14:05, Rouslan Placella a écrit : >>>> And this one would make an interesting merge conflict :D >>> >>> You forgot to merge QA_3_4 back into master after applying the fixes, >>> which I guess you didn't actually cherry-pick due to the differences in >>> whitespace distribution, so it left some interesting conflicts for the >>> next person merging QA_3_4 into master... >> >> Oops, sorry. Fortunately the correct way to resolve them was to use >> the file from master. > > Then oops me too, because during the merge I used the hunks of code from > QA_3_4 when resolving conflicts. It made sense to me at the time to keep > the code from the two branches as similar to each other as possible... The more we progress in 3.5 development, the more we'll see code differences and it will be easier to fix non-urgent bugs only in master. -- Marc Delisle http://infomarc.info --===============2242103879546077168==-- From piotr.prz@gmail.com Fri Jul 15 19:19:35 2011 From: Piotr Przybylski To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Fri, 15 Jul 2011 21:19:24 +0200 Message-ID: In-Reply-To: <1310753116.2252.49.camel@roccivic-pc> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8280439761600819003==" --===============8280439761600819003== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 2011/7/15 Rouslan Placella : > On Fri, 2011-07-15 at 20:00 +0200, Piotr Przybylski wrote: >> 2011/7/15 Rouslan Placella : >> > On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote: >> >> 2011/7/14 Marc Delisle : >> >> > Le 2011-07-14 15:43, Piotr Przybylski a =C3=A9crit : >> >> >> 2011/7/14 Marc Delisle: >> >> >>> Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit : >> >> >>>> 2011/7/14 Marc Delisle: >> >> >>>>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit : >> >> >>>>>> Hi, >> >> >>>>>> >> >> >>>>>> Is XML export used at all? It was missing data escaping in many >> >> >>>>>> places, and structure (table, function, ...) export was just bro= ken. I >> >> >>>>>> fixed it a bit, but there are still some problems that remain: >> >> >>>>>> - escaping of table/db names and data in other encodings than IS= O-8859-1 >> >> >>>>>> - it uses SHOW CREATE TABLE without any required fixes >> >> >>>>>> >> >> >>>>>> File format itself is interesting. I don't expect XML Schema for= it to >> >> >>>>>> exist, but at least namespace usage should be consistent. >> >> >>>>>> >> >> >>>>>> I think fixing this and rewriting output format to be more consi= stent >> >> >>>>>> should appear on Tasks for junior developers. And maybe extendin= g it >> >> >>>>>> to output data in more concise format, eg.: >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> value >> >> >>>>>> ... >> >> >>>>>> >> >> >>>>>> ... >> >> >>>>>>
>> >> >>>>>> >> >> >>>>> Piotr, >> >> >>>>> XML export is probably used, how can we know? >> >> >>>> >> >> >>>> Maybe nobody needs DDL in it or we have too few people using it to >> >> >>>> report bugs :) >> >> >>>> >> >> >>>>> In your testing, was it just a problem in master or also in 3.4.x? >> >> >>>>> >> >> >>>> >> >> >>>> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to expo= rt >> >> >>>> table `evil'"*/>` with all options selected. You will get only data >> >> >>>> (no structure) and invalid XML >> >> >>> >> >> >>> Can you backport your fixes to QA_3_4? >> >> >>> >> >> >> >> >> >> Yes. Just to be sure I don't break anything - what's the proper way = of doing it? >> >> >> 1. Create a local branch traacking origin/QA_3_4 >> >> >> 2. cherry-pick my commits to master >> >> >> 3. push >> >> >> ? >> >> >> >> >> > >> >> > This should work. >> >> >> >> Thanks. >> >> > Usually you should have started with QA_3_4, like explained on >> >> > http://wiki.phpmyadmin.net/pma/Git#Committing_fixes_to_several_branch= es. >> >> >> >> Too late now, I had to suffer from all these merge conflicts :) >> >> >> >> > The big mistake to avoid is merging master to QA_3_4! >> >> >> >> And this one would make an interesting merge conflict :D >> > >> > You forgot to merge QA_3_4 back into master after applying the fixes, >> > which I guess you didn't actually cherry-pick due to the differences in >> > whitespace distribution, so it left some interesting conflicts for the >> > next person merging QA_3_4 into master... >> >> Oops, sorry. Fortunately the correct way to resolve them was to use >> the file from master. > > Then oops me too, because during the merge I used the hunks of code from > QA_3_4 when resolving conflicts. It made sense to me at the time to keep > the code from the two branches as similar to each other as possible... > I will fix that tomorrow. --=20 Piotr Przybylski --===============8280439761600819003==-- From rouslan@placella.com Fri Jul 15 19:35:19 2011 From: Rouslan Placella To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Fri, 15 Jul 2011 20:35:07 +0100 Message-ID: <1310758507.2252.62.camel@roccivic-pc> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1299172736749278243==" --===============1299172736749278243== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 2011-07-15 at 21:19 +0200, Piotr Przybylski wrote: > 2011/7/15 Rouslan Placella : > > On Fri, 2011-07-15 at 20:00 +0200, Piotr Przybylski wrote: > >> 2011/7/15 Rouslan Placella : > >> > On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote: > >> >> 2011/7/14 Marc Delisle : > >> >> > Le 2011-07-14 15:43, Piotr Przybylski a =C3=A9crit : > >> >> >> 2011/7/14 Marc Delisle: > >> >> >>> Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit : > >> >> >>>> 2011/7/14 Marc Delisle: > >> >> >>>>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit : > >> >> >>>>>> Hi, > >> >> >>>>>> > >> >> >>>>>> Is XML export used at all? It was missing data escaping in many > >> >> >>>>>> places, and structure (table, function, ...) export was just b= roken. I > >> >> >>>>>> fixed it a bit, but there are still some problems that remain: > >> >> >>>>>> - escaping of table/db names and data in other encodings than = ISO-8859-1 > >> >> >>>>>> - it uses SHOW CREATE TABLE without any required fixes > >> >> >>>>>> > >> >> >>>>>> File format itself is interesting. I don't expect XML Schema f= or it to > >> >> >>>>>> exist, but at least namespace usage should be consistent. > >> >> >>>>>> > >> >> >>>>>> I think fixing this and rewriting output format to be more con= sistent > >> >> >>>>>> should appear on Tasks for junior developers. And maybe extend= ing it > >> >> >>>>>> to output data in more concise format, eg.: > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> value > >> >> >>>>>> ... > >> >> >>>>>> > >> >> >>>>>> ... > >> >> >>>>>>
> >> >> >>>>>> > >> >> >>>>> Piotr, > >> >> >>>>> XML export is probably used, how can we know? > >> >> >>>> > >> >> >>>> Maybe nobody needs DDL in it or we have too few people using it = to > >> >> >>>> report bugs :) > >> >> >>>> > >> >> >>>>> In your testing, was it just a problem in master or also in 3.4= .x? > >> >> >>>>> > >> >> >>>> > >> >> >>>> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to ex= port > >> >> >>>> table `evil'"*/>` with all options selected. You will get only d= ata > >> >> >>>> (no structure) and invalid XML > >> >> >>> > >> >> >>> Can you backport your fixes to QA_3_4? > >> >> >>> > >> >> >> > >> >> >> Yes. Just to be sure I don't break anything - what's the proper wa= y of doing it? > >> >> >> 1. Create a local branch traacking origin/QA_3_4 > >> >> >> 2. cherry-pick my commits to master > >> >> >> 3. push > >> >> >> ? > >> >> >> > >> >> > > >> >> > This should work. > >> >> > >> >> Thanks. > >> >> > Usually you should have started with QA_3_4, like explained on > >> >> > http://wiki.phpmyadmin.net/pma/Git#Committing_fixes_to_several_bran= ches. > >> >> > >> >> Too late now, I had to suffer from all these merge conflicts :) > >> >> > >> >> > The big mistake to avoid is merging master to QA_3_4! > >> >> > >> >> And this one would make an interesting merge conflict :D > >> > > >> > You forgot to merge QA_3_4 back into master after applying the fixes, > >> > which I guess you didn't actually cherry-pick due to the differences in > >> > whitespace distribution, so it left some interesting conflicts for the > >> > next person merging QA_3_4 into master... > >> > >> Oops, sorry. Fortunately the correct way to resolve them was to use > >> the file from master. > > > > Then oops me too, because during the merge I used the hunks of code from > > QA_3_4 when resolving conflicts. It made sense to me at the time to keep > > the code from the two branches as similar to each other as possible... > > >=20 > I will fix that tomorrow. I'm not sure if there is much to "fix", the code is fine, I was only talking about formatting/whitespaces. Rouslan --===============1299172736749278243==-- From piotr.prz@gmail.com Fri Jul 15 20:48:00 2011 From: Piotr Przybylski To: developers@phpmyadmin.net Subject: Re: [Phpmyadmin-devel] XML export Date: Fri, 15 Jul 2011 22:47:50 +0200 Message-ID: In-Reply-To: <1310758507.2252.62.camel@roccivic-pc> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4214027977213311978==" --===============4214027977213311978== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 2011/7/15 Rouslan Placella : > On Fri, 2011-07-15 at 21:19 +0200, Piotr Przybylski wrote: >> 2011/7/15 Rouslan Placella : >> > On Fri, 2011-07-15 at 20:00 +0200, Piotr Przybylski wrote: >> >> 2011/7/15 Rouslan Placella : >> >> > On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote: >> >> >> 2011/7/14 Marc Delisle : >> >> >> > Le 2011-07-14 15:43, Piotr Przybylski a =C3=A9crit : >> >> >> >> 2011/7/14 Marc Delisle: >> >> >> >>> Le 2011-07-14 09:24, Piotr Przybylski a =C3=A9crit : >> >> >> >>>> 2011/7/14 Marc Delisle: >> >> >> >>>>> Le 2011-07-13 18:28, Piotr Przybylski a =C3=A9crit : >> >> >> >>>>>> Hi, >> >> >> >>>>>> >> >> >> >>>>>> Is XML export used at all? It was missing data escaping in ma= ny >> >> >> >>>>>> places, and structure (table, function, ...) export was just = broken. I >> >> >> >>>>>> fixed it a bit, but there are still some problems that remain: >> >> >> >>>>>> - escaping of table/db names and data in other encodings than= ISO-8859-1 >> >> >> >>>>>> - it uses SHOW CREATE TABLE without any required fixes >> >> >> >>>>>> >> >> >> >>>>>> File format itself is interesting. I don't expect XML Schema = for it to >> >> >> >>>>>> exist, but at least namespace usage should be consistent. >> >> >> >>>>>> >> >> >> >>>>>> I think fixing this and rewriting output format to be more co= nsistent >> >> >> >>>>>> should appear on Tasks for junior developers. And maybe exten= ding it >> >> >> >>>>>> to output data in more concise format, eg.: >> >> >> >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> value >> >> >> >>>>>> ... >> >> >> >>>>>> >> >> >> >>>>>> ... >> >> >> >>>>>>
>> >> >> >>>>>> >> >> >> >>>>> Piotr, >> >> >> >>>>> XML export is probably used, how can we know? >> >> >> >>>> >> >> >> >>>> Maybe nobody needs DDL in it or we have too few people using it= to >> >> >> >>>> report bugs :) >> >> >> >>>> >> >> >> >>>>> In your testing, was it just a problem in master or also in 3.= 4.x? >> >> >> >>>>> >> >> >> >>>> >> >> >> >>>> Also in 3.4.x (STABLE). Go to database `evil'"*/>` and try to e= xport >> >> >> >>>> table `evil'"*/>` with all options selected. You will get only = data >> >> >> >>>> (no structure) and invalid XML >> >> >> >>> >> >> >> >>> Can you backport your fixes to QA_3_4? >> >> >> >>> >> >> >> >> >> >> >> >> Yes. Just to be sure I don't break anything - what's the proper w= ay of doing it? >> >> >> >> 1. Create a local branch traacking origin/QA_3_4 >> >> >> >> 2. cherry-pick my commits to master >> >> >> >> 3. push >> >> >> >> ? >> >> >> >> >> >> >> > >> >> >> > This should work. >> >> >> >> >> >> Thanks. >> >> >> > Usually you should have started with QA_3_4, like explained on >> >> >> > http://wiki.phpmyadmin.net/pma/Git#Committing_fixes_to_several_bra= nches. >> >> >> >> >> >> Too late now, I had to suffer from all these merge conflicts :) >> >> >> >> >> >> > The big mistake to avoid is merging master to QA_3_4! >> >> >> >> >> >> And this one would make an interesting merge conflict :D >> >> > >> >> > You forgot to merge QA_3_4 back into master after applying the fixes, >> >> > which I guess you didn't actually cherry-pick due to the differences = in >> >> > whitespace distribution, so it left some interesting conflicts for the >> >> > next person merging QA_3_4 into master... >> >> >> >> Oops, sorry. Fortunately the correct way to resolve them was to use >> >> the file from master. >> > >> > Then oops me too, because during the merge I used the hunks of code from >> > QA_3_4 when resolving conflicts. It made sense to me at the time to keep >> > the code from the two branches as similar to each other as possible... >> > >> >> I will fix that tomorrow. > > I'm not sure if there is much to "fix", the code is fine, I was only > talking about formatting/whitespaces. > Yes, there's only formatting that differs so I won't change anything. --=20 Piotr Przybylski --===============4214027977213311978==--