The problem was a call to convert_dirname() with a destination buffer
that did not have room for the trailing slash added by that function.
This could cause the instance manager to crash in some cases.

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

- correction of backport error

- make sure to disable bulk insert when check for duplicate key is needed

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

corrupt
  - add infinite retry on drop table temporary error

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

- always calculate max log level on node start
- send event subscribe uncond

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

    ndb: ndb_waiter disconnect/reconnect on get status error

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

- not having lock can cause "block number list" to become corrupt => crash
- also may result in 2 threads receiving same block no => possble cause of
Bug #13987 Cluster: Loss of data nodes can cause high CPU usage from ndb_mgmd

into  poseidon.ndb.mysql.com:/home/tomas/mysql-4.1

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

- invalidate ndb dict cache on cluster disconnect (ClusterMgr.cpp)
- add check for correct frm on external lock when table cache is found invalid

replaced get_field(MEM_ROOT *mem, Field *field) with 
get_field(MEM_ROOT *mem, Field *field, String *res).
It allows to avoid strlen().

into mysql.com:/home/gluh/MySQL/Merge/5.0

into mysql.com:/home/gluh/MySQL/Merge/5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into mysql.com:/home/gluh/MySQL/Merge/5.0

into  mysql.com:/home/mysql-5.0-10418

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

 - Don't kill the active connection to the server, instead read 
   the connection id, switch connection and kill the first one from there.

a worse execution plan than in 4.1 for some queries.
It happened due the fact that at some conditions the 
optimizer always preferred range or full index scan access
methods to lookup access methods even when the latter were much
cheaper. 
The problem was not observed in 4.1 for the reported query
because the WHERE condition was not of a form that could
cause the problem.
Equality propagation introduced on 5.0 added an extra 
predicate and changed the WHERE condition. The new condition
provoked the optimizer to make a bad choice.

The problem was fixed by the patch for bug 17379.

into  zippy.(none):/home/cmiller/work/mysql/mysql-5.0-maint

into  mysql.com:/home/mysql-4.1-10418

into  mysql.com:/home/mysql-5.0-19263

  Compile in all character sets in Max (bug#14918)