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.: <table name=""> <row> <column_name>value</column_name> ... </row> ... </table>
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.:
<table name=""> <row> <column_name>value</column_name> ... </row> ... </table>
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?
2011/7/14 Marc Delisle marc@infomarc.info:
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.:
<table name=""> <row> <column_name>value</column_name> ... </row> ... </table>
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).
Le 2011-07-14 09:24, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
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.:
<table name=""> <row> <column_name>value</column_name> ... </row> ... </table>
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).
2011/7/14 Marc Delisle marc@infomarc.info:
Le 2011-07-14 09:24, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
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.:
<table name=""> <row> <column_name>value</column_name> ... </row> ... </table>
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 ?
Le 2011-07-14 15:43, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
Le 2011-07-14 09:24, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
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.:
<table name=""> <row> <column_name>value</column_name> ... </row> ... </table>
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?
- Create a local branch traacking origin/QA_3_4
- cherry-pick my commits to master
- push
?
This should work. Usually you should have started with QA_3_4, like 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!
2011/7/14 Marc Delisle marc@infomarc.info:
Le 2011-07-14 15:43, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
Le 2011-07-14 09:24, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
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.:
<table name=""> <row> <column_name>value</column_name> ... </row> ... </table>
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?
- Create a local branch traacking origin/QA_3_4
- cherry-pick my commits to master
- 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
On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote:
2011/7/14 Marc Delisle marc@infomarc.info:
Le 2011-07-14 15:43, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
Le 2011-07-14 09:24, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
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.: > <table name=""> > <row> > <column_name>value</column_name> > ... > </row> > ... > </table> > 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?
- Create a local branch traacking origin/QA_3_4
- cherry-pick my commits to master
- 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...
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
2011/7/15 Rouslan Placella rouslan@placella.com:
On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote:
2011/7/14 Marc Delisle marc@infomarc.info:
Le 2011-07-14 15:43, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
Le 2011-07-14 09:24, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info: > 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.: >> <table name=""> >> <row> >> <column_name>value</column_name> >> ... >> </row> >> ... >> </table> >> > 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?
- Create a local branch traacking origin/QA_3_4
- cherry-pick my commits to master
- 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.
On Fri, 2011-07-15 at 20:00 +0200, Piotr Przybylski wrote:
2011/7/15 Rouslan Placella rouslan@placella.com:
On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote:
2011/7/14 Marc Delisle marc@infomarc.info:
Le 2011-07-14 15:43, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info:
Le 2011-07-14 09:24, Piotr Przybylski a écrit : > 2011/7/14 Marc Delislemarc@infomarc.info: >> 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.: >>> <table name=""> >>> <row> >>> <column_name>value</column_name> >>> ... >>> </row> >>> ... >>> </table> >>> >> 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?
- Create a local branch traacking origin/QA_3_4
- cherry-pick my commits to master
- 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.
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
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.
2011/7/15 Rouslan Placella rouslan@placella.com:
On Fri, 2011-07-15 at 20:00 +0200, Piotr Przybylski wrote:
2011/7/15 Rouslan Placella rouslan@placella.com:
On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote:
2011/7/14 Marc Delisle marc@infomarc.info:
Le 2011-07-14 15:43, Piotr Przybylski a écrit :
2011/7/14 Marc Delislemarc@infomarc.info: > Le 2011-07-14 09:24, Piotr Przybylski a écrit : >> 2011/7/14 Marc Delislemarc@infomarc.info: >>> 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.: >>>> <table name=""> >>>> <row> >>>> <column_name>value</column_name> >>>> ... >>>> </row> >>>> ... >>>> </table> >>>> >>> 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?
- Create a local branch traacking origin/QA_3_4
- cherry-pick my commits to master
- 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.
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.
On Fri, 2011-07-15 at 21:19 +0200, Piotr Przybylski wrote:
2011/7/15 Rouslan Placella rouslan@placella.com:
On Fri, 2011-07-15 at 20:00 +0200, Piotr Przybylski wrote:
2011/7/15 Rouslan Placella rouslan@placella.com:
On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote:
2011/7/14 Marc Delisle marc@infomarc.info:
Le 2011-07-14 15:43, Piotr Przybylski a écrit : > 2011/7/14 Marc Delislemarc@infomarc.info: >> Le 2011-07-14 09:24, Piotr Przybylski a écrit : >>> 2011/7/14 Marc Delislemarc@infomarc.info: >>>> 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.: >>>>> <table name=""> >>>>> <row> >>>>> <column_name>value</column_name> >>>>> ... >>>>> </row> >>>>> ... >>>>> </table> >>>>> >>>> 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.
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.
Rouslan
2011/7/15 Rouslan Placella rouslan@placella.com:
On Fri, 2011-07-15 at 21:19 +0200, Piotr Przybylski wrote:
2011/7/15 Rouslan Placella rouslan@placella.com:
On Fri, 2011-07-15 at 20:00 +0200, Piotr Przybylski wrote:
2011/7/15 Rouslan Placella rouslan@placella.com:
On Thu, 2011-07-14 at 23:59 +0200, Piotr Przybylski wrote:
2011/7/14 Marc Delisle marc@infomarc.info: > Le 2011-07-14 15:43, Piotr Przybylski a écrit : >> 2011/7/14 Marc Delislemarc@infomarc.info: >>> Le 2011-07-14 09:24, Piotr Przybylski a écrit : >>>> 2011/7/14 Marc Delislemarc@infomarc.info: >>>>> 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.: >>>>>> <table name=""> >>>>>> <row> >>>>>> <column_name>value</column_name> >>>>>> ... >>>>>> </row> >>>>>> ... >>>>>> </table> >>>>>> >>>>> 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.
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.
-
Marc Delisle -
Piotr Przybylski -
Rouslan Placella