On Thu, Apr 26, 2001 at 08:51:45AM -0500, Ben Collins-Sussman wrote:
> 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.
[snip]
> 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?
Yeah, I understand what you're saying now, and it makes more sense.
But I still disagree. I don't think we should partition tests this
way. I think we should do as much as possible to make sure that every
representation of every change is consistent. Otherwise, the test
suite will miss things that it could catch, which I think would be a
serious problem.
What I would evntually like to see is something like this:
return compare_lots_of_trees(exp_tree, wc_tree, output_tree . . .)
So that you just verify the consistency of everything. Obviously, for
updates, for example, you can't use the sam wc_tree as for checkouts,
since the update doesn't touch the whole tree. But I think we should
try for as much consistency as possible.
> > > 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?
Well, I think it is worth it. That allows us to keep .add_child
private as well, which I also think is a good thing. The less we
expose the internal implementation of svn_tree to the rest of the
suite, the more flexible we can be with that implementation.
Also, I would think that it should be possible to write a function
that does the job of both build_tree_from_paths and
build_generic_tree, by determining what kind of input it was passed.
Actually, what I would really like is a single build_tree function,
which figured out what it was passed, and just did the right thing. I
think this can be done, and I think it would allow for more
implementation hiding, which is almost always a good thing.
> > > 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.)
No, using it in the real tests would be foolish. But it's very useful
for debuggin the test suite itself.
>
> >
> > > # 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.
Well, I don't have a strong preference, except that your function
includes the top-level wc directory in the tree, which as I explained
in my other email (the not-calm one :-) is a mistake. The only way
that I could think of to fix that was the following hack at the end of
wc_to_tree:
root.children = root.children[0].children
I think that's not the optimal solution. If there's an easy way to do
this with your function that I missed, then that's fine. Otherwise,
the one I wrote does the right thing already. Your choice.
> 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.
>
Will do.
sam th --- sam_at_uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dynds.org/decss
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:29 2006