-C Fix\sa\srecently\sintroduced\sproblem\swith\sdeleting\sentries\sfrom\sindex\stables.\s(CVS\s5754)
-D 2008-09-30T09:31:45
+C Change\sleading\stabs\sinto\sspaces.\s(CVS\s5755)
+D 2008-09-30T14:06:29
F Makefile.arm-wince-mingw32ce-gcc fcd5e9cd67fe88836360bb4f9ef4cb7f8e2fb5a0
F Makefile.in e4ab842f9a64ef61d57093539a8aab76b12810db
F Makefile.linux-gcc d53183f4aa6a9192d249731c90dbdffbd2c68654
F src/auth.c c8b2ab5c8bad4bd90ed7c294694f48269162c627
F src/bitvec.c 95c86bd18d8fedf0533f5af196192546e10a7e7d
F src/btmutex.c 709cad2cdca0afd013f0f612363810e53f59ec53
-F src/btree.c 2e5cf91c3f342fa611bfd6f0250c31b432fbdd90
+F src/btree.c b7fbd31bd8b856abf86582451dd89418ee2112d0
F src/btree.h 6371c5e599fab391a150c96afbc10062b276d107
F src/btreeInt.h 3e93c0a6f363bbf68fdd975620f4d3671b6cf7bc
F src/build.c 160c71acca8f643f436ed6c1ee2f684c88df4dfe
F tool/speedtest2.tcl ee2149167303ba8e95af97873c575c3e0fab58ff
F tool/speedtest8.c 1dbced29de5f59ba2ebf877edcadf171540374d1
F tool/speedtest8inst1.c 293327bc76823f473684d589a8160bde1f52c14e
-P 15dd0169a4c5e2ff9e3894eec10799cb89d462e5
-R 67ac196eea416fb3e08d66e37fb1b4f0
-U danielk1977
-Z 769068257f0c5361c027fdd2793aa895
+P 83c064cae481ca95b7107e22e98fc599fe85a2da
+R 319340bfa62e8f2b4a8c5cb2fb651da4
+U drh
+Z 27a83ef36caf191b09200aa330c8990e
** May you share freely, never taking more than you give.
**
*************************************************************************
-** $Id: btree.c,v 1.521 2008/09/30 09:31:45 danielk1977 Exp $
+** $Id: btree.c,v 1.522 2008/09/30 14:06:29 drh Exp $
**
** This file implements a external (disk-based) database using BTrees.
** See the header comment on "btreeInt.h" for additional information.
** It is not possible to copy the ancestry from pCur, as the same
** balance() call has invalidated the pCur->apPage[] and aiIdx[]
** arrays.
- **
- ** The call to saveCursorPosition() below internally saves the
- ** key that leafCur is currently pointing to. Currently, there
- ** are two copies of that key in the tree - one here on the leaf
- ** page and one on some internal node in the tree. The copy on
- ** the leaf node is always the next key in tree-order after the
- ** copy on the internal node. So, the call to sqlite3BtreeNext()
- ** calls restoreCursorPosition() to point the cursor to the copy
- ** stored on the internal node, then advances to the next entry,
- ** which happens to be the copy of the key on the internal node.
- ** Net effect: leafCur is pointing back where
+ **
+ ** The call to saveCursorPosition() below internally saves the
+ ** key that leafCur is currently pointing to. Currently, there
+ ** are two copies of that key in the tree - one here on the leaf
+ ** page and one on some internal node in the tree. The copy on
+ ** the leaf node is always the next key in tree-order after the
+ ** copy on the internal node. So, the call to sqlite3BtreeNext()
+ ** calls restoreCursorPosition() to point the cursor to the copy
+ ** stored on the internal node, then advances to the next entry,
+ ** which happens to be the copy of the key on the internal node.
+ ** Net effect: leafCur is pointing back where
*/
#ifndef NDEBUG
Pgno leafPgno = pLeafPage->pgno;