Re: MySQL uses PRIMARY key when it should? use another index

[Joerg Bruehe]

Hi Vasil, all !


I can comment on the BK aspect only:

Vasil Dimov wrote:
> [[...]]
> 
> The outcome is that the tree, cloned with -r1.2604.71.1 has the "old"
> behavior (t1ba index is used) while the tree cloned with -r1.2635.3.5
> has the "new" behavior. The thing is that both trees differ in 7692
> lines. I would expect they to differ only by the change that was
> introduced in 1.2635.3.5 (one line fix) because they are adjacent in the
> list of changesets:
> http://mysql.bkbits.net:8080/mysql-5.1/?DATE=-4w..&PAGE=changes
> 
> What am I missing here?

You have to differ between two different ways of looking at changesets:
a) by commit time order (on the developer machines),
b) by merge sequence (to the source tree used).

A graphical representation of the tree history can be done as a directed 
graph, with the changesets (commits) as nodes and the clone/pull/push 
operations as arcs.
Then, you can order the nodes in time sequence (by the commit time).

This order ("a") is what the "bk changes" command uses in its output.

But the fact that two changesets are next to each other in this order 
does not imply that they have any close relationship, especially that 
the second of them resulted in a tree contents of "the first plus just 
this change":
The second may have been applied to a tree which did not contain the 
first change at all, and it happens only much later in a merge that they 
meet each other.

> 
> How can I further dig and find the changeset that caused the behavior to
> change?

I do not know of any simple BK command which does it.

It might be possible using "bk changes -e", which should also list the 
(empty) merge changesets, and then doing lots of manual analysis which 
tree got merged when.  I do not propose that approach.


When we build a MySQL release, we need the "ChangeLog" file to contain 
the "bk changes" output of all changesets which are in the current 
version but haven't been in the previous one - very similar to your search.

The simple approach of "bk changes -rOLD,NEW" fails, because it uses the 
commit time order ("a"), and so it will miss all those changesets in NEW 
which were committed before OLD but merged after it.

We use "bk set -d -r OLD -r NEW" to construct a (mathematical) set of 
changesets, those which form the set difference ("-d") of the trees as 
of the OLD and NEW revisions.
We then pipe that to a "bk changes -vm -" command which outputs the 
changeset comments.  Simplified:
    bk set -d -r OLD -r NEW  |  bk changes -vm -  > ChangeLog

Sadly, I cannot tell whether and how this can be achieved using the free 
client "bkf".


Regards,
and a Happy New Year,
Jörg

-- 
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com