[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: WC-NG: the trees BASE, WORKING and ACTUAL [was: svn commit: r33021 - branches/explore-wc/subversion/libsvn_wc]

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 11 Sep 2008 15:27:58 -0700

On Thu, Sep 11, 2008 at 1:38 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Maybe you don't have the same definition of "a tree" as I do. I am
> assuming we mean the sort of tree that is described by a Subversion
> delta editor. A tree of nodes; each node is either a file or a dir; each
> node has properties; each dir has 0 or more child nodes; each file has
> content which is a blob of 0 or more bytes.


> When you say, "Files/dirs present, but not in WORKING: unversioned
> nodes", what about them? They are part of the ACTUAL tree? Yes, I say.

ACTUAL, yes.

> When you say, "Files/dirs in WORKING, but not present: missing nodes",
> what about them? They are part of the ACTUAL tree? Yes, I say.

No. Those nodes are *missing* from ACTUAL. They should be there since
WORKING says they should be. Thus, they are missing.

> And files/dirs that are in WORKING and present on disk as nodes of the
> correct type? Yes, I say. How about you?

In both WORKING and ACTUAL, yes.

> And files/dirs that are on disk where WORKING says there's a node of the
> other type? Yes, I say. How about you?

The node is in both WORKING and ACTUAL, but there is now a problem. I
don't know that we have a name for this kind of change. This isn't
really unversioned or missing... something else.

Also: note that we should be talking about symlinks, too. They are
moving to a first-order node type in the new WC library.

> And the properties of each node are?

Whatever WORKING says about the properties. ACTUAL cannot represent them.

Unversioned nodes (things in ACTUAL, but not WORKING) will (obviously)
have no properties.

>> >> BASE + Subversion-managed changes = WORKING.
>> >> WORKING + non-Subversion-managed changes = ACTUAL.
>> Yup. Note that WORKING *may* include text-mod flags. If somebody does
>> an "svn edit", then a flag will get recorded saying "looks like this
>> file was modified" (or is likely to have been). But WORKING is purely
>> an admin thing. You have to look at ACTUAL to find *real* text mods.
> You're now talking about WORKING including "flags". This is not
> impossible: I've wondered whether these "trees" need to be augmented by
> bits of metadata like this. So, are you're saying that the term "WORKING
> tree" defines of a set of state recorded in the implementation, rather
> than defining an abstract tree concept?

Not sure what you mean by "recorded in the implementation". The
WORKING tree has a set of flags (and other state) that records its
delta from BASE. Simple as that.

>> > represent? It seems to me that it represents an implementation artifact:
>> > the set of modifications that Subversion records explicitly in its
>> > meta-data rather than the modifications that Subversion scans for
>> > dynamically. That's not a distinction of much interest to the higher
>> > layers of software.
>> WORKING is entirely an admin thing. To find the complete set of
>> modifications, you also have to look at the ACTUAL files which
>> correspond to WORKING files. (you don't have to examine the entire
>> ACTUAL tree! ... sometimes unversioned files are irrelevant)
> Ahh... I was envisaging these "kinds of tree" as concepts that would be
> visible through the API. That there would be ways to ask through the
> API, "what are the differences between our WORKING tree and our ACTUAL
> tree?" (so I can remind the user that they need to issue some Subversion
> tree-rearrangement commands), or "what is the value of svn:mime-type on
> the WORKING version of file 'foo'?" (so I can display it in an
> appropriate editor).
> That's where I want there to be a clear external concept of "I'm asking
> about the user's working version" versus "Now I'm asking the same
> question about the pristine version".

Right. And the API embodies that. There are functions with "_base_" in
the name. Those operate *only* on the BASE tree (aka "pristine").

There are other APIs that operate on the WORKING/ACTUAL tree. The line
here gets a bit fuzzier. The ACTUAL tree can only differ from WORKING
in very limited ways. And the idea of a "modified file in the WORKING
tree" comes from the ACTUAL tree: that is where the contents are
located, where they get modified, and where the state information is

> Whether we need to expose three
> trees, to be able to distinguish not only the pristine version but also
> between the working version as told to Subversion, and the nodes on disk
> as modified outside Subversion, I'm not 100% sure, but it seems
> reasonable that we do need to distinguish these.

Yes. The BASE is very distinct, and has separate APIs to operate on
it. The WORKING/ACTUAL is a much more grey boundary, and the API
doesn't try to expose them as two entirely separate trees.

Definitely seems that it would be a Good Thing to enumerate how these
two trees can differ. It is a finite list. I'll update the doc with


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-12 00:28:13 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.