On Thu, Apr 26, 2001 at 04:37:52PM -0500, Ben Collins-Sussman wrote:
> Sam TH <sam@uchicago.edu> writes:
>
> > 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.
>
Whichever. It doesn't really matter to me. The build_tree_*
definitely need access to the internals of the structure, but I think
it would be better if other stuff just used them, as opposed to
building trees themselves.
> > 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.
Well, I personally am a big believer in "sufficently advanced
technology" (magic). I think it affords us more flexibility in using
the interface. But if you object to that style, it's not a big issue
for me.
> 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.
>
Makes sense.
>
> > > 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.
The nameless root node is definitely neccessary, for the reasons you
described. The problem is with the next node. Maybe this will
explain it better.
You're generating trees that look like this:
ROOT
|
+-- wc-t1
|
|-- iota
+-- A
etc.
The problem is with the wc-t1 node, which we don't want, since it
isn't a property of the working copy, and will be different with a
different working copy that we might want to compare with. What we
want is a tree like this:
ROOT
|
|-- iota
+-- A
etc.
The latter is the kind generated by build_generic_tree(). The former
is generated by wc_to_tree(). The way I got wc_to_tree to generate
the latter kind of tree was with the hack I mentioned above.
Is that clearer? Is there a better way to do this in your
wc_to_tree()?
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