Branko Čibej <br...@wandisco.com> writes: > The combiner only produces target copies if the source delta(s) contain > them. We shouldn't be generating any since we started using the xdelta > algorithm instead of vdelta; I don't really understand why BDB would be > using vdelta instead, not even for compatibility reasons.
A compressed dump file is only 7K. Loading this into a BDB repo
generates svn_txdelta_target ops during post-commit deltification:
#0 svn_txdelta__insert_op (build_baton=0x7fffffffc340,
opcode=svn_txdelta_target, offset=2321, length=1, new_data=0x0,
pool=0x7ffff5558028) at ../src/subversion/libsvn_delta/text_delta.c:222
#1 0x00007ffff7f8ce6d in svn_txdelta_compose_windows (
window_A=0x7fffffffc490, window_B=0x7ffff5550278, pool=0x7ffff5558028)
at ../src/subversion/libsvn_delta/compose_delta.c:811
#2 0x00007ffff72d8111 in compose_handler (window=0x7fffffffc490,
baton=0x7fffffffd670)
...
#13 0x00007ffff72dac33 in svn_fs_base__rep_deltify (fs=0x7ffff7e2d050,
target=0x7ffff55918a8 "f", source=0x7ffff5591b18 "d",
trail=0x7ffff55970f8, pool=0x7ffff5591028)
at ../src/subversion/libsvn_fs_base/reps-strings.c:1494
#14 0x00007ffff72d1700 in maybe_deltify_mutable_rep (
target_rep_key=0x7ffff55918a8 "f", source_rep_key=0x7ffff5591b18 "d",
txn_id=0x7ffff5599140 "8", trail=0x7ffff55970f8, pool=0x7ffff5591028)
at ../src/subversion/libsvn_fs_base/dag.c:1490
...
#21 0x00007ffff72e352e in svn_fs_base__deltify (fs=0x7ffff7e2d050, revision=8,
pool=0x7ffff55ac028) at ../src/subversion/libsvn_fs_base/tree.c:2956
#22 0x00007ffff7fa6130 in svn_fs_deltify_revision (fs=0x7ffff7e2d050,
revision=8, pool=0x7ffff55ac028)
at ../src/subversion/libsvn_fs/fs-loader.c:1508
I might use this dump file to create a test.
x.x.gz
Description: compressed dump file
-- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
