Re: CVS update: MODIFIED: libsvn_wc ...

"Sander Striker" <striker@apache.org> writes:

> I don't know if this patch is really needed, but I do think that
> visiting a dir only once justifies the extra cost of sorting like
> this.

--
Greg Stein <gstein@lyra.org> writes:
> > Thus, the crawler
> > is *already* sorting the targets.  As Mike said, right now the targets
> > are being qsorted alphabetically, which guarantees that all children
> > in the same directory will be examined as a group.  
> 
> Nope. It *isn't* doing that, which is why I posted the question in the first
> place. If we were doing a proper traversal, then we wouldn't need to check
> whether a lock had been taken out already. Thus, Mike's change to look for
> an existing lock is merely covering up a deeper issue (that was my worry).
--
Statements like this make it pretty obvious that people do NOT
understand what's currently going on.
1.  We are not 'visiting a dir' more than once.  We visit once, we do
    some things to children of that dir, and then we're done.  Sure,
    some of the children of that dir are directories themselves and
    require some recursion, but that's irrelevant.
2.  Yes, the paths are being sorted alphabetically, with attention
    given to path separators so that each child is only visited once,
    but NOT such that directory children are visited before
    non-directory children.  In fact, such determination *could not*
    be made without polling the disk, which is outside the domain of
    knowledge this function requires, or should require.  
    Take this example:
       svn ci foo baz/bie baz/bell bar
    Now, our sorted targets will be:
       bar baz/bell baz/bie foo
    Are they files?  Are they dirs?  We can safely assume that baz is
    a directory, but can't make any assumptions about bar or foo.
    *Who cares*.  We visit the parent directory of bar, baz, and foo,
    and crawl bar, baz/bell, baz/bie, and foo.  When we finish with
    baz/bie, we exit that recursion and yes, we've forgetting that our
    parent directory is already locked -- which is why we now check
    that fact before locking again.
Will someone who actually understands the code please tell me what the
problem with this scenario is?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org