On Dec 20, 2007 5:04 AM, C. Michael Pilato <email@example.com> wrote:
> C. Michael Pilato wrote:
> > David Glasser wrote:
> >> On Dec 19, 2007 7:50 PM, Eric Gillespie <firstname.lastname@example.org> wrote:
> >>> In tightening up the operational logging, I've encountered
> >>> another mystery. dav_svn__update_report looks for
> >>> "resource-walk" from the client, but I'm not really sure what
> >>> that causes it to do. It doesn't really matter, though, as serf
> >>> *never* sends this and neon has code in fetch.c:make_reporter to
> >>> send it, but no make_reporter calls use it!
> > [...]
> >> I found this code a couple of months ago, was concerned about its
> >> interaction with something new (depth?), and eventually realized it
> >> was pretty dead. Wasn't sure what to do though.
> > The resource walk was used at the end of 'switch' operations as a way for
> > the client to rebuild the wc-props cache. It was later found to be lacking
> > in certain situations, so we instead taught our clients to invalidate all
> > the wc-props before doing the real switch work, and then repopulating them
> > lazily as info became available. The server-side logic exists for
> > compatability for older clients (who, by the way, won't know anything of the
> > new depth support).
> > (If this helps to explain things, perhaps you could take the above and slap
> > it in as a comment at just the right spot in the code?)
> Oh! All that said, a new non-official client (such as SVNKit) could still
> request the resource-walk, so we *should* make it depth-aware.
Is requesting the resource-walk something you can do by reading our
include/svn_*.h functions and calling an svn_foo function, or just
something you can do by reverse-engineering our WebDAV protocol (or
admittedly reading the notes/webdav-protocol doc)? If the latter, I
don't see why we need to support it; I thought our policy has always
been that we make it as easy as possible to bind to us, but if you
want to reverse-engineer, goo luck.
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Dec 20 17:26:40 2007