into  riska.(none):/home/sven/bkroot/5.1-bugteam

Temporarily checking in an incorrect test case. Rationale: the impact of
this bug is negligible (it's almost a feature request). We need 5.1 to be
stable, and making a real fix is a bit risky. So the fix is postponed
to 6.0.

The test suite/rpl/t/rpl_innodb_bug28430.test was disabled because of
BUG#32247, but not re-enabled when BUG#32247 was fixed. I've re-enabled
it. The test and result file needed to be updated too.

- Disable the "prefer full scan on clustered primary key over full scan
  of any secondary key" rule introduced by BUG#35850.
- Update test results accordingly 
(bk trigger: file this for BUG#35850)

into  mysql.com:/Users/davi/mysql/mysql-5.1-bugteam

into  mysql.com:/Users/davi/mysql/mysql-5.1-bugteam

The problem is that the patch for Bug 33464 didn't update the
results of the test cases which caused the problem.

Dropping a stored routine also revoke privileges for all users
on the stored routine and errors about missing grants are converted
into warnings. Before Bug 33464 such errors could be incorrectly
returned to the user, which would later trigger a assertion due to
multiple errors being set.

into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-bugteam

into a non-const string pointer.

into  mysql.com:/Users/davi/mysql/mysql-5.1-bugteam

into  noir.wlan.koehntopp.de:/misc/mysql/mysql-5.1-bugteam

We could allocate chunks larger than 4GB, but did our size-accounting in 32-bit
values. This could lead to spurious warnings, inaccurate accounting, and, in
theory, data loss.

Affected: 64-bit platforms. Debug-build (with safemalloc). At least one buffer
larger than 4GB. For potential data loss, a re-alloc on such a buffer would be
necessary.

into  mysql.com:/Users/davi/mysql/mysql-5.1-bugteam

    Bug#31237 Test "ndb_views" fails because of differing order of select results

into  magare.gmz:/home/kgeorge/mysql/work/merge-5.1-bugteam

into  magare.gmz:/home/kgeorge/mysql/work/merge-5.0-bugteam

into  mysql1000.dsl.inet.fi:/home/andrei/MySQL/BARE/mysql-5.1-bugteam

The problem is a hack in mysqltest.c::append_field that modifies
the exponential notation of floating point numbers by removing a
zero after the the symbol 'e' (eg: 00001.2e+018 is converted to
00001.2e+18) but does not take into account the zerofill affect
in the start of the string.

The solution is to check if the field was zero filled and insert
a zero at the start of the string if a zero after the exponential
notation symbol is removed.

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-bugteam

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-bugteam

 - Code in DbugParse was reading from beyond end of the control string

into  pcrews-mac-local.local:/Users/pcrews/usr/local/bin/data0/build_work/mysql-5.1-trigs

into  pcrews-mac-local.local:/Users/pcrews/usr/local/bin/data0/build_work/mysql-5.0-trigs

into  pcrews-mac-local.local:/Users/pcrews/usr/local/bin/data0/build_work/mysql-5.1-trigs

into  pcrews-mac-local.local:/Users/pcrews/usr/local/bin/data0/build_work/mysql-5.1-trigs

Bug#36028 - Test funcs_1.<engine>_trig_03e failing on Windows
Bug#36029 - Test funcs_1.<engine>_trig_0407 failing on Windows
Bug#36030 - Test funcs_1.<engine>_trig_08 failing on Windows

Adding $MASTER_MYSOCK to init_win_path()
When path names are short, master.sock ends up in MYSQL_TMP_DIR, but with longer path names,
master.sock ends up in /tmp/<random_string>/ and these tests will fail due to path delimiter difference.

New changeset to start with 5.0 -- Not all of these tests are present in 5.0, but want to keep mysqltest the same

into  magare.gmz:/home/kgeorge/mysql/autopush/B36041-5.1-bugteam

into  magare.gmz:/home/kgeorge/mysql/autopush/B36041-5.1-bugteam

into  magare.gmz:/home/kgeorge/mysql/autopush/B35298-5.1-bugteam

into  magare.gmz:/home/kgeorge/mysql/work/merge-5.1-bugteam

into  magare.gmz:/home/kgeorge/mysql/work/B35298-5.1-bugteam

The bug is a regression introduced by the patch for bug32798.

The code in Item_func_group_concat::clear() relied on the 'distinct'
variable to check if 'unique_filter' was initialized. That, however,
is not always valid because Item_func_group_concat::setup() can do
shortcuts in some cases w/o initializing 'unique_filter'.

Fixed by checking the value of 'unique_filter' instead of 'distinct'
before dereferencing.

into  magare.gmz:/home/kgeorge/mysql/work/merge-5.0-bugteam

into  magare.gmz:/home/kgeorge/mysql/work/merge-5.1-bugteam