On Thu, 2008-09-11 at 11:57 -0700, Greg Stein wrote:
> In short, I'm not seeing any reason to modify the definitions. Mike
> explained them rather well, and I don't see any problems with those
> On Thu, Sep 11, 2008 at 10:47 AM, Julian Foad
> <julianfoad_at_btopenworld.com> wrote:
> > Getting warmer. How about:
> > * ACTUAL is the tree on the local disk, ignoring Subversion
> > administrative directories, and regarding every node as having
> > no Subversion properties.
> Eh? That's just what is on disk. I'm not sure that is a relevant tree.
> What is on disk is only relevant in the context of a working copy.
> More specifically, how it relates/differs from WORKING.
> Files/dirs present, but not in WORKING: unversioned nodes
> Files/dirs in WORKING, but not present: missing nodes
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.
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.
And files/dirs that are in WORKING and present on disk as nodes of the
correct type? Yes, I say. How about you?
And files/dirs that are on disk where WORKING says there's a node of the
other type? Yes, I say. How about you?
And the properties of each node are?
> >> 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?
> > I was also questioning the intent of defining WORKING as a tree that has
> > the BASE file contents. That seems silly: what useful concept does that
> It doesn't "have them" ... it is just that most of the WORKING tree's
> contents == BASE's contents, simply because they haven't been
> modified. There isn't any real "container" or "superset" or anything.
OK, I think we agree there.
> > 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
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". 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.
Clearly we're not yet seeing eye to eye. I hope we're getting a bit
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:38:57 CEST