Comment 12 for bug 415508

I'm still wondering whether this is meant to return the sha1 of the canonical or convenient content.

The steps seem to be:

1- rename get_path_content_summary to say get_canonical_content_summary; remove the size field. So then it will return (kind, exec, sha1_or_link_target).

2- there don't seem to be any record_entry_contents tests yet but we could add some, presumably per_repository.

3- if the test of step 2 is failing, we could merge john's branch and expect that it will then pass.

Ian pointed out that bzr-svn and bzr-git might rely on this interface. It would be nice to avoid breaking them. If they provide this interface but don't call it, we might be able to have a clean migration path.

I'm wondering here if we should actually have another Tree object that represents the filtered view of the tree, rather than proliferating methods with filtered=bool parameters. But that can be done separately.

The code that does filtering, eg internal_size_sha_file_byname seems to return both the size and the hash so it seems like any problem that affects one should affect the other.

I think before changing get_path_content_summary we need to be clear about what the code that's currently using it expects the behaviour to be, whether that's to return the filtered or unfiltered content.