On Thu, 2003-10-30 at 17:46, Greg Stein wrote:
> I think part of the point here is that the direction you're going with
> this is very unclear. And given an unknown on overall direction, it is
> further unclear on whether to provide feedback on the branch. What are the
> specific goals [of the branch] at this time that we should compare your
> development against?
Sorry, we forgot to send a mail. Kfogel, Cmpilato and I read over the
recent list discussion, had more discussions, then discussed them even
more on IRC with ghudson and sander. We just haven't mailed the list
yet. Here's my explanation.
The old plan was to expand the editor interface, adding a boolean
'incomplete' argument to close_directory(). Whenever part of a working
copy was unable to be sent (due to authz failure), we'd simply skip over
the missing item and trigger that incomplete flag when closing the
directory: "hey, this directory is missing stuff."
But what bugged us about this solution is that it leaves the working
copy in a permanent state of incompleteness. 'svn status' always shows
the incomplete dir. It's a bit ugly for the user. When a CVS directory
is incomplete, the user has no idea. Why should a
partially-unauthorized SVN checkout look broken all the time?
Sander and cmpilato then pointed out that we *already* have "ghost"
entries. They're those special 'deleted' entries. 'svn status' ignores
them, and so does just about every other command. At the moment, these
phantom entries only happen when you commit the deletion of something,
or if you update an object to a revision where it's gone. But now we
have a 3rd case: one of these 'deleted' entries can be the result of
failed authz on the server, a failed retrieval.
It's much nicer to have a complete directory containing a few 'deleted'
phantom entries, rather than have an incomplete directory.
>From there, we decided that it's probably better to stop calling the
flag 'deleted': a more general term is "absent". It could be absent
for any three of the reasons listed above -- it could result from a
commit, an update, or a failed authz retrieval. (Our compatibility plan
here, by the way, is to rename this flag by having our entries-parser
look for both 'deleted' and 'absent', but always write out 'absent'.
We'll probably have to bump the wc-format revnum too, so old libsvn_wc's
don't choke on new working copies. But I digress.)
Let me get back on track here: this means we're going for a different
editor change now. Instead of adding a boolean 'incomplete' to
close_dir(), we're creating two new editor functions: absent_file() and
absent_dir(). These functions mean, "this object exists, but I'm not
sending it to you." The update-editor's implementations of these
functions will either create an 'absent' ghost entry, or convert an
existing entry to 'absent', effectively disconnecting the file or dir
from the working copy. If the authz policy changes on the server, and
suddenly you have the ability to read these things, 'svn up' will
continue to report them to the server (as it already does), and poof,
they'll be sent down for real... no more phantom entries. It works out
great.
Now, how about the server side? We still need to have the server
process do authz 'subrequests', that was always part of our plan. But
we didn't want this to be a pure mod_dav_svn change: imagine how hacky
it would be if dir_delta (the uber-editor-driver) were driving
mod_dav_svn's editor with an add_dir(), and then mod_dav_svn discovers
authz failure on the dir, and instead transmits an absent_dir() across
the network. Whoops, dir_delta() still recurses into the unreadable
dir, and mod_dav_svn needs to ignore all that extra, pointless info
coming in. Yuck.
So instead, we decided to push the authz hook check *into* dir_delta()
itself. svn_repos_dir_delta() will now call a generic authz callback
supplied by mod_dav_svn, svnserve, or any other future server process.
Authz is now part of libsvn_repos, available to all servers. If the
authz callback returns failure, dir_delta() *itself* will send an
absent_foo() editor call, and efficiently skip over the item.
Ultimately, after all this stuff is done, we're going to finally apply
the patch-in-progress (in the issue) and finish it. The patch is
mod_dav_svn specific, giving it the ability to send inline textdeltas in
the REPORT response. Only it's going to be expanded not just to marshal
inline textdeltas, but absent_foo() calls as well. Eventually, as
gstein points out, we'll be removing the neon shim stuff in
libsvn_ra_dav as well... we can't be holding all txdelta CDATA in memory
at once.
That's the plan. Anyone still listening? :-)
A final note: the *only* reason we're working on a branch is so that we
can commit in chunks that feel logical to us, and not have to worry
about whether the code compiles or runs at each stopping point. A
branch isn't strictly necessary; it just gives us some breathing room.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 31 08:13:16 2003