On Thu, 2008-09-11 at 12:19 -0700, Greg Stein wrote:
> On Thu, Sep 11, 2008 at 9:13 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> >...
> > That definition of ACTUAL is a rather special case of a "tree": it is
> > not a complete Subversion tree on its own, because it doesn't know
> > anything about properties.
>
> I see no problem with that.
I see a problem with that as a potential API user, if the API exposes
the concept of "ACTUAL tree" in a way that can involve properties. I
want to know what the API is going to tell me about these nodes'
properties. Or must the WC design have absolutely no place in the API
where it is possible to ask the WC to expose information about
properties when asking about the ACTUAL tree? If that is the case, for
example, if there is a "diff between BASE and WORKING" API which does
expose property diffs, and there is a "diff between WORKING and ACTUAL"
API which cannot expose property diffs, then they have to have two
different diff-representation interfaces.
What I'm saying is it would be better to define that the properties of
the nodes in the ACTUAL tree are none (or that they are the same as the
WORKING tree, or something, anything, as long as it's defined) so that
we can then share APIs like 'svn_wc_diff_callbacks3_t' and use them in a
deterministic way.
> > I feel that each definition of a "tree" needs to be the definition of a
> > complete tree including properties and file contents, so that it is
> > meaningful to perform any generic tree operation such as iteration, diff
> > against another tree, recursive propget, etc. without throwing an error.
>
> Ugh. One of the problems with the current WC is that it is hard to
> tell *which* tree is being operated upon. Part of this effort is to
> always make it clear which trees are being read/modified. In other
> words, "generic tree operations" might be counter to cleaning this up.
If every API was generic and you had to specify which trees you wanted
it to operate on, that would be ugly. And if the three trees were
considered equal by every API, then the APIs and the WC in total
wouldn't be doing the things that make it special. There has to be a
bunch of special treatment, but it is immensely helpful if some of the
information-getting APIs like "proplist" and "get file content" can be
generic w.r.t. which tree they get from.
One obvious form of special treatment is in the APIs that modify the
working version. (mkdir, propset, etc.) These obviously only apply to
the WORKING/ACTUAL trees (perhaps jointly).
> > I think the most important concept to represent through one of these
> > trees is the user's view of their "working copy": the complete tree that
>
> This is WORKING plus the file modifications that are found in ACTUAL.
> In the API when you read file contents for WORKING, they're going to
> come from ACTUAL.
Ahhh... good. I didn't notice you saying that anywhere else. So, from an
API user's point of view, the WORKING tree DOES include the contents of
the disk files, yes?
> ACTUAL is only relevant when you're looking for unversioned or missing nodes.
OK.
> >...
> > Do we want to amend the definition in that way?
>
> I don't think so.
Well, maybe not in that way exactly, but there's a lot it doesn't
say :-)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-11 22:55:15 CEST