On 30-11-10 15:24, SourceForge.net wrote:
> Patches item #3055886, was opened at 2010-08-30 10:21
> Message generated for change (Comment added) made by kai-schaetzl
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=377410&aid=3055886&group_…
>
I think we could make this last suggestion happen, it makes sense.
What would be a sensible default ... 20?
And would it not be confusing for users?
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions
Welcome to the second alpha release of phpMyAdmin 3.4.0. This release
contains new features, especially:
* User preferences
* Relation schema export to multiple formats
* ENUM/SET editor
* Simplified interface for export/import
* AJAXification of some parts
* Charts
* Visual query builder
Details will appear on http://phpmyadmin.net. In a hurry? you can visit
http://sourceforge.net/projects/phpmyadmin to download.
Marc Delisle, for the team
Hi all,
I was looking to solve a bug [0], and found some differences between
master and QA_3_3 (where QA_3_3 seemed correct). I wondered why it was
changed and found that the change was introduced by a merge I did [1]
: commit 20a402ba29776f2ed1ba3122e48df98bfc11cafe
But what's strange about this commit is that it seems to merge two
commits. One of mine, where I solved a bug (diff1 [2]) and another one
(diff2 [3]), where the reported bug [0] is introduced.
When I try to figure out where this commit comes from, I only find it
was committed by me. But I'm quite sure I didn't. Moreover because
that commit changes a lot of files, and I changed only ChangeLog and
server_status.php
So I'm a bit confused now : Where did this commit come from? Who did
it? Why did it end up in my merge (according to git), but it doesn't
show up in the original report I got by mail when committing this
merge? And more important : should it be reversed?
I would be grateful if anyone could explain what happened back then.
[0] : https://sourceforge.net/tracker/?func=detail&aid=3119874&group_id=23067&ati…
[1] : http://phpmyadmin.git.sourceforge.net/git/gitweb.cgi?p=phpmyadmin/phpmyadmi…
[2] : http://phpmyadmin.git.sourceforge.net/git/gitweb.cgi?p=phpmyadmin/phpmyadmi…
[3] : http://phpmyadmin.git.sourceforge.net/git/gitweb.cgi?p=phpmyadmin/phpmyadmi…
--
Greets,
Dieter Adriaenssens
Welcome to the first alpha release of phpMyAdmin 3.4.0. This release
contains new features, especially:
* User preferences
* Relation schema export to multiple formats
* ENUM/SET editor
* Simplified interface for export/import
* AJAXification of some parts
* Charts
* Visual query builder
Details will appear on http://phpmyadmin.net. In a hurry? you can visit
http://sourceforge.net/projects/phpmyadmin to download.
Marc Delisle, for the team
Hi Marc,
I noticed you created several branches preparing for the 3.4.0 release.
Are there any guidelines for merging? For instance, when I fix a bug
in QA_3_3, should it be applied to MAINT_3_4, QA_3_4 and master?
Or will from now on, only security fixes be applied to QA_3_3?
--
Kind regards,
Dieter Adriaenssens
2010/11/15 Marc Delisle <marc(a)infomarc.info>:
> Dieter Adriaenssens a écrit :
>
>> Hi Marc,
>>
>> Apparently, your latest bugfix in QA_3_3 was not merged with master
>> yet. It merged automatically when I merged my changes in QA_3_3 to
>> master.
>> I hope this is not a problem.
>>
> Hi Dieter,
> in my tests, the fix was not needed for master. I'll test again to ensure
> that the "fix" does not make things worse.
Hi Marc,
OK, was there a way I could have avoided this accidental merge?
Usually I just do
$git merge QA_3_3
in master after a commit to the QA_3_3 branch. (As mentioned on the
developers wiki [0])
There is a possibility of just merging the commit, instead of the
branch. But I guess that this is an exceptional case were a patch in
QA_3_3 didn't have to be applied to master, so the procedure as
mentioned on the wiki is still valid (and the more straight forward
one).
[0] http://wiki.phpmyadmin.net/pma/Devel:Git#Committing_fixes_to_several_branch…
Kind regards,
Dieter
Hi,
In 3.4 I would like to label this option "Do not abort on INSERT error"
because talking about duplicate rows is misleading. INSERT IGNORE has
other effects than just continuing insertion on duplicate keys.
The current message can make a user believe that no duplicate rows will
be inserted even if unique keys are not properly defined.
--
Marc Delisle
http://infomarc.info