On Thu, 2008-09-11 at 08:27 -0700, Greg Stein wrote:
> Thanks for the thoughts.
>
> Note that we need to be able to iterate over all three trees. This
> code just iterates over WORKING, so it won't even have to stat(). I'll
> need to expand this now to be able to iterate over BASE (no stats) and
> over ACTUAL (use readdir), so I can see what those look like.
>
> Now that I think about it, the read_info() needs to be able to signal
> an unversioned item when iterating over ACTUAL.
When we say "WORKING" and "ACTUAL", I'm wondering what exactly we mean
by each of them.
>From notes/wc-ng-design:
> * WORKING: The tree as it is in modified form, based on the
> administrative information recorded by the transforming
> 'svn ..' commands
> Note: This tree will -as far as text bases goes- generally
> overlap with BASE, but isn't required to;
> e.g. "add-with-history"
>
> * ACTUAL: The tree as it is in modified form on the local disk.
> This tree may differ from WORKING when having been modified
> with non-Subversion transforming commands (such as plain 'rm').
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 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.
If so, then maybe we ought to say that ACTUAL is defined as the above,
with a note that in this tree's view there are no properties on any
node.
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.
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
they think of as the one on which Subversion will perform operations
such as commit, diff, status and propset. This could be defined as:
* WORKING: The tree that represent's the user's view of their
Subversion working copy with their local modifications. That is,
the tree structure and properties defined by the administrative
information recorded by the transforming 'svn ...' commands,
and the file content on the local disk. (Where a file cannot
be accessed because the tree structure on the local disk does
not accord, ...?)
Do we want to amend the definition in that way?
(If we were not to define ACTUAL and WORKING as complete trees, but were
to define them partially and require the higher layer libraries to
access both WORKING and ACTUAL and combine the results themselves, that
would be escalating a task that is, I think, the WC's responsibility.)
- Julian
> On Thu, Sep 11, 2008 at 7:26 AM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
> > Hi Greg,
> >
> >> +svn_error_t *
> >> +generic_walker(svn_wc__db_t *db,
> >> + const char *path,
> >> + walker_func_t walk_func,
> >> + void *walk_baton,
> >> + apr_pool_t *scratch_pool)
> >...
> >
> > When I look at one of the current problems in the WC is that we use a
> > database to determine what *should* be there, then using stat() to
> > find out if it's actually there. This is one of our biggest
> > performance problems.
> >
> > I have been thinking that we could try to shift that around: using
> > readdir() to determine what's there and then using the database to
> > find out if our administration agrees. This way, stat()s could be
> > concentrated, probably even optimized by the OS, instead of requiring
> > single stat() calls for everything we want to know.
> >
> > Not that there's anything wrong with the design above, even with what
> > I describe there may still be use-cases for this API, I just wanted to
> > point out that using a BASE or WORKING tree as the basis to operate
> > from (instead of the ACTUAL tree) may perpetuate existing problems.
---------------------------------------------------------------------
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 18:14:10 CEST