> "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.
*blink* *blink* I'm starting to see the light now.
> 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.
So, why is it trying to lock the parent again? Is this just an artifact
from the way svn sets the 'current directory' to edit?
> Will someone who actually understands the code please tell me what the
> problem with this scenario is?
No problem with it. I was just trying to prevent the 'current dir' from
changing* if there were items to do that didn't need recursion. Ofcourse,
like you said above, it isn't possible to tell from the path names. You
could defer the recursive items until the non-recursive ones are exhausted,
but it isn't needed.
*) And thus preventing the code from trying to lock again.
Just ignore the previous comments, thanks for explaining.
Btw, the last lines in the patch still hold and save a call to strncmp().
Sander
PS. The reason for saying the code was visiting a dir twice is that
'changing the current dir' to a dir counts as a visit. In the scenario
above you drop out of the recursion and 'change the current dir' to
the parent again (== revisit). Terminology, language barriers, all
very nice :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:39 2006