Re: svn commit: r33021 - branches/explore-wc/subversion/libsvn_wc

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 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.

>...
> In the above definition of WORKING, I don't quite understand the comment
> about "overlap with BASE" and "add-with-history". Does it mean, "...
> where the file contents in this tree are those in the BASE tree"? That
> would seem odd to me.

As I said in my other note: it simply means that many of the nodes are
the same. Not that one tree includes another.

> 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.

ACTUAL is only relevant when you're looking for unversioned or missing nodes.

>...
> Do we want to amend the definition in that way?

I don't think so.

Cheers,
-g

---------------------------------------------------------------------
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 21:19:32 CEST