Sam TH <sam@uchicago.edu> writes:
> 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.
I just can't wrap my brain around your Grand Unified Tree Theory. Can
you give examples of how it might work? Or problems it would solve?
> 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.
That's exactly why I'm confused. What does a "universal tree" mean in
your world?
Since examining disk contents is highest priority, let's assume that
any given "tree" object represents all information about a working
copy: it's structure, file contents, and properties.
Now, when I get subcommand output that looks like
D /foo/bar
A /foo/baz/bop
UU /gleeb/blort
You want to write python code that actually *understands* the status
codes and modifies a pristine tree object? And then compare this tree
to actual working copy on disk?
This seems enormously complex to me. It sounds like you're basically
talking about re-implementing libsvn_wc in python. Besides... how
could you possibly modify the tree object to match what's on disk?
No subcommand output actually describes the textual or property
patches coming in.
That's why I think the *best* we can do is match regular expressions
against subcommand output. That's what I was doing before you came
along. Your trees are great -- I can use them as (essentially fancy)
regexp matchers on subcommand output, and can use slightly different
trees to examine disk contents. There's already a whole lot of
elegance and overlap going on. But I just can't see the our use-cases
of trees ever coming together. It doesn't make sense to me.
> 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.
Hmm.... then maybe I should just keep it simple and throw everything
back into svn_tree: all the general tree stuff, plus all funcs that
build-tree-from-foo(). Then they can keep on using the private stuff.
> 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.
Hmmm. This is a matter of style, I guess. I personally dislike
overlapping functionality just because it's possible -- there's a
tradeoff in the readability. I usually think it's clearer to export
two different interfaces for two different jobs -- and let them share
factorized code under the hood -- rather than create one "do it all"
interface.
But actually, now that I think about it -- I don't think
build_tree_from_paths will ever be used anymore. We're never going to
want to build a completely empty tree; we'll *always* want some kind
of contents or props in there. That function will probably obsolece.
> > 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
Hm. I put the question up for debate... is it really wrong to always
create a 'nameless' root node as the absolute parent? I argue that
it's a convenience.
* when I want to verify subcommand output, it's nice to have a
'nameless' root node for relative paths that are printed:
A/D/G/rho
A/mu
iota
* when I want to verify disk trees, it's nice to always start the
pathlist with the name of the working copy dir.
Of course, we could do the other way, which I think would involve
putting an implicit "." on my first example. Erg, bikeshed.
Received on Sat Oct 21 14:36:29 2006