Can you describe the circumstances? Is it that we log file foo/bar and bar was added in rev X, but isn't in rev X-1. Which causes the filter logic to include foo in X but not X-1? IMO filter was a hack to try to make bzr log dir faster, which helped a lot before 2a, but the new data just does it differently. There are bugs about bzr log dir should be faster, where I've at least done analysis of ways we could tweak it. (Essentially, we expect the number of entries in a subdir to be more than the number of entries in each delta, so we should do delta first, and filter second.) So, I don't think we are attached to current behaviour. John =:-> <div class="gmail_quote">On Oct 15, 2011 2:29 PM, "Jelmer Vernooij" <<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Repository.get_revision_delta() retrieves a TreeDelta object for a revision. It can, if requested filter out only the requested file ids. The docstring for specific_file_ids says: :param specific_fileids: if not None, the result is filtered so that only those file-ids, their parents and their children are included. However, in terms of actual behaviour this seems to mean that a parent can be in delta.added, even if it wasn't changed in the specified revision. This seems wrong to me, but we do actually have a test that verifies this behaviour (bzrlib/tests/per_repository/test_repository.py:297). Is the test correct, or should it be fixed to expect the parent to show up in .unchanged rather than .added? Cheers, Jelmer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a> iQIcBAEBAgAGBQJOmXyHAAoJEACAbyvXKaRXfLgP/AuvJRJleidIHurJO8cjEi/6 Uh6PFHsQ0NnOimZVol8l+nlvdTnlndRg1TLsRDvE5g1bJ4NtjbKq4ZJI/lFe7gHR TZrGx+20PXN5/y/fMHLaJiUmtXScqLmfojmZLw1GTGMym+jD5bzXfhWuG2st/5Ow GFiypRJIHp3jNl7GhZzbWXJy5uQY9ugw3KCvLWu6Ykk5Qgrs0y8q6riMshyL9DmU 4SPj4TVVXx5hyz/FtLIY9MW+eWHVztuEaNsbjbzpu2hroCMq2WnOap7snDvZL00x 4ZGJfS51qv6n6bs9Fy1uC9Q5Tppm8Ag8WVZr+V4jiVm8YBPD2gtAQruGCXMXMe/b ZnbUTxbM8XEFhVlt87b62LX6m8l/KlUF9Zxp4jx3D+yLmblITDgxq2Tmiz6UokDL GZbn9byVNWBXh5d02xSWBhFRhpsz5yoxunn2Xg2PlipHysLcrZt9/rVQFgHaAbkn xvjiPlX3UzmkiyOIxWJ6MCBdc8o51cFXqsPmn5+N/3uLTle+z3pGicHNKMncBoLW XBjNVmj6ArkKeEFsYLw7rbidB3IVp6HAKOIoi5U0/3VC4E32gyMVNRzykYaTWZFe U0TFSPIY/BG+04VZqNBE9ze7q5G/GRcNAUA14/XjR2dqF04TO1SeTZRAJ5jYpbTg ia/wRlmesoiJbZMJlVvK =SWjv -----END PGP SIGNATURE----- </blockquote></div>