r848366 | cmpilato | 2004-01-14 16:36:42 +0000 (Wed, 14 Jan 2004)
Finish issue #1695 - svn_fs__bdb_changes_fetch() fouls up change
ordering. Now, as we're summarizing the changes, deletions and
replacements of paths will cause us to forget about any previous
changes that occured in that transaction on children of the
deleted/replaced path (unless, of course, those children are
re-created *after* the deletion/replacement of their parent).
This bug only manifests itself in filesystems written to by clients
that don't do their commits in depth-first order. To my knowledge,
cvs2svn is the only one that meets this criteria. But the result is
an otherwise working Subversion repository on which you cannot run
'svn log' or 'svnadmin dump' across revisions in which deletions
happened not-depth-first.
A big ol' thanks to Geoffrey C. Speicher <geoff@sea-incorporated.com>
who not only noticed the bug, but graciously (and patiently) helped me
with test data and with testing the fix.
Review by: Geoffrey C. Speicher <geoff@sea-incorporated.com>
* subversion/libsvn_fs/bdb/changes-table.c
(make_change): Removed.
(fold_change): Const-ify 'change' argument. Also, fold in the guts
of make_change() here -- no need to call a helper function this
small from one place.
(svn_fs__bdb_changes_fetch): If we fold a deletion or replacement
into the changes hash, we need to forget about any previous
changes that existed on child paths of our deleted/replaced path.
* subversion/tests/libsvn_fs/changes-test.c
(changes_fetch_ordering): New test.
(test_funcs): Add new test.