[RFC] Using TestCaseWithMemoryTree

Robert Collins robertc at robertcollins.net
Thu Apr 26 00:26:27 BST 2007

On Wed, 2007-04-25 at 13:11 -0500, John Arbash Meinel wrote:
> I've started switching new test cases over to using
> "make_branch_and_memory_tree()", and in general, I'm very happy about
> the performance improvements. Especially on my Mac laptop, it makes
> setting up the tests a lot faster.
> The only deficiency I'm specifically aware of deals with the ability to
> add files and directories (and modify their contents). If we were able
> to do that, then probably 90% of the tests could be rewritten. Tests for
> WorkingTree have to stay on disk, and we probably need a test or two
> that Branch and Repository can work on the disk, but both of those
> classes should be completely abstracted through Transport, and we have a
> very rigorous interface testing of Transport functionality.

So my overarching goal here is to have MutableTree's interface be
sufficient for what you want. That should also make it sufficient for
TreeTransform if done with care.

> I think one of the limitations is that MemoryTree creates its own
> MemoryTransport which it doesn't expose for TestCase.build_tree() to
> modify. If we exposed the transport, we could do:
> self.build_tree(['a', 'b'], transport=mem_tree.transport)

I'd rather we didn't do that, but instead work with treebuilder to make
it more comprehensive.

> The only other part I'm aware of, is that MemoryTree doesn't support
> sprout() and merge/pull_from_branch(). Part of the reason is that those
> functions need to modify the working tree, and we can't do that in
> memory....

right. This is deliberate - its all about what the classes are for.

I'll update the MemoryTree doco today.

but for now:
MemoryTree is designed as a tool to aid testing logic within bzrlib that
depends on the tree interface but is not testing the tree logic itself.

A test for e.g. merge should not use MemoryTree
A test for 'branch.FOO' should be able to use memorytree.

theres one hole in this, which is Branch.sprout, where the Branch
interface leaks slighly as it wants to create a tree, but appropriate
use of a parameterised format should allow even that to use a

> In my latest tests I've worked around that by directly calling
> "tree.branch.set_last_revision_info()" and "tree.set_parent_ids()".
> Which lets me create whatever ancestry I want, by just jumping around as
> necessary. In the past I've done it by creating one Tree, sprouting it
> to another, and then merging between the two.

Using tree.set_parent_ids() is the expected way of doing it.

> Is this a reasonable way of doing it? If so, it would be nice to have a
> Test function to make it easier. Because right now you need to change
> both the Tree and the Branch to be at the right location (or when you
> commit you get "Out of date, please run 'bzr update'").

Yes, we should wrap these helpers up somewhere.

Hmm, that might be a nice warm up today. Expect something soon.

GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070426/a4b0b990/attachment-0001.pgp 

More information about the bazaar mailing list