On Thu, 2008-09-11 at 13:16 -0400, C. Michael Pilato wrote:
> Julian Foad wrote:
> > On Thu, 2008-09-11 at 12:51 -0400, Greg Stein wrote:
> >> Those are the correct definitions, per wc-by-design.
> > (I assume you mean, "per 'notes/wc-ng-design'".)
> > Both of you:
> > Huh? I was trying to refine the definitions to something more precise
> > than "ACTUAL is how the working copy really looks." :-)
> I don't know how better to explain it. Uh... ACTUAL is the state of a
> working copy directory if you imagine its not a Subversion working copy?
> ACTUAL is what you see with shell tools like 'ls'?
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.
(Note that we might want to consider variations such as
"... having no Subversion properties except for 'svn:executable' set
to '*' iff the node's executable-by-owner permission is set."
"... except as defined by the user's auto-props configuration."
"... excluding nodes with the operating system's 'hidden' flag set."
> A "missing" file is caused by the ACTUAL directory lacking a file for which
> the BASE tree contains a file of the same name, and for which the WORKING
> tree does *not* indicate that the physical file should be absent (such as
> would be expected were the file scheduled for deletion).
> BASE + Subversion-managed changes = WORKING.
> WORKING + non-Subversion-managed changes = ACTUAL.
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
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.
I submit that it is much more sensible to define WORKING as I suggested
in my earlier mail. (i.e. having the disk file contents)
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 19:48:09 CEST