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.