Sam TH <sam@uchicago.edu> writes:
> How are you planning on handling verification for updates? Since it's
> only going to be a subset of the on-disk tree, we can't just compare
> it against the working copy directly. Comparing it against a set of
> expected results is easy, but that's not enough. Here's my current
> thought - [...]
>
> [...]
>
> At various places, you're constructing trees with entirely different
> property sets, which we are going to want to compare later. For
> example, you can't get the 'verb' from a working copy. Nor can you
> get the text from an import command. How do you plan to do these
> comparisons?
Sam, you're mixing apples and oranges. We have one set of tools for
verifying subcommand output, and another set of tools for verifying
disk contents. I have no intention to mix them. Yes, a single test
might use them both, but not actually compare their trees.
Here's an example:
1. Checkout a working copy, capture subcommand output into tree1
2. Compare tree1 against a generated 'expected' tree (this expected
tree is created by running build_generic_tree() on a specific
list of lists.)
3. Create tree2 by scanning the working copy.
4. Compare tree2 against a different generated 'expected' tree.
Here's a more specific example, for an update test. If we only expect
the update to print:
_U /foo/bar
U /foo/baz
A bop
Then the expected tree we compare against is the return value of this:
expected_tree = svn_tree.build_generic_tree
([ ['/foo/bar', None, {'status' : '_U'}],
['/foo/baz', None, {'status' : 'U '}],
['bop', None, {'status' : 'A '}] ]
So yes, here's a case where we'll be comparing two stubby little trees
-- but that's ok. Your tree comparison function is general enough.
Not every tree we make has to represent a working copy. :)
Of course, the *next* part of the test would be to examine disk
contents after the update using full-size trees.
Am I making sense?
>
>
> > + if svn_tree.compare_trees(exp_tree, result_tree):
> > + return 0
> > + else:
> > + return 1
>
> Since you changed the return values, these are of course broken. Not
> that this file current runs anyway. Fixes later.
Heh, thanks. Will fix.
> > ###########################################################################
> > # EXPORTED ROUTINES
> >
> >
> > # General utility: change one path into a linked list of nodes.
> > #
> > # (Take the output and .add_child() it to a root node.)
> >
> > def create_from_path(path, contents=None, props={}):
>
> I don't think this should be an exported routine. It would be nice to
> get svn_output to use build_tree_from_paths, if possible. This
> function is really an implementation detail. (As is the neat merging
> features of .add_child, for that matter.)
I want to keep all the subcommand-tree-building routines in
svn_output.py. The problem is that build_tree_from_paths() currently
isn't general enough... if you want to hide create_from_path(), then
build_tree_from_paths() would need to take contents and props for each
node. And then the function would necessarily end up looking exactly
like build_generic_tree()!
So what's the best thing to do? Make every function in svn_output.py
parse subcommand output into a list-of-lists, and then use
build_generic_tree() to parse the list-of-lists into a generic tree?
It seems a little obtuse... do you think it's worth it in exchange for
keeping create_from_path() private?
>
> > def dump_tree(n,indent=""):
> > "Print out a nice representation of the tree's structure."
>
> I think this should at least print some property info, if nothing
> else. And whether the node is a directory or not.
Go for it. Honestly, I don't think this function will ever be used by
our tests. It may be used to test our tree-building ability -- but
not to test subversion. (Though the output looks great! Please make
sure Prof. Beazley doesn't mind us using it.)
>
> > # helper for wc_to_tree() -- callback for os.walk()
> > def visitfunc(baton, dirpath, entrynames):
> > "Callback for os.walk(). Builds a tree of SVNTreeNodes."
>
> Why did you decide to use os.path.walk() instead of the tree walker I
> wrote? I found the one with walk() harder to understand (although
> that may have to do with having written the other one) and the baton
> stuff seems ugly (although we wouldn't want to be the only part of
> subversion without batons).
Ummmmmmm.... I'm quite embarrassed. I didn't see it!
Oh crud. I just realized that the svn_tree.py file that I was hacking
was in fact not the 'latest' version you sent. It didn't contain your
build_tree_from_wc(). Ugh, talk about reinventing the wheel.
Looking at your handle_dir() right now. It looks good. Do you have
strong opinion about switching to it? I think they're both about the
same. Don't really care.
Instead, it's your build_tree_from_entries() function that I just
discovered and am *really* interested in. Let's start a thread on
that... I want to understand exactly what it does, and how it can help
us.
>
> >
> > def wc_to_tree(wc_path, load_props=0):
>
> I think this ought to be called build_tree_from_wc, for consistency.
Good idea.
>
> > svn_tree.dump_tree(wc_to_tree('wc-t1'))
>
> It's a good idea to hide this behind
>
> if __name__ == '__main__':
>
> so that it doesn't get executed on import.
Oh, it will be deleted. It's just a temporary test line.
Received on Sat Oct 21 14:36:29 2006