On Fri, Feb 09, 2001 at 03:10:28PM -0600, Ben Collins-Sussman wrote:
>
> Hah! You thought the phone call was over!
>
> There was still some "unsureness" revolving around whether it was Good
> that the RA layer receive the update-target-list, and whether it was
> good that RA use this target list to drive the update-editor.
>
> Karl pointed out that it may not be *necessary*, based on the fact
> that the revison-reporting vtable might somehow be able to directly
> cause the filestem to produce a tree-delta.
It may not be necessary simply due to the fact that you can derive it from
the reported revision information. As each revision comes it, it will:
1) occur "under" a previously reported path
2) top of a new, disjoint path
It is possible (depending on the report driver), however:
3) occurs "over" previously report path(s)
In any case, once you have the complete set of paths, the "top" of those
paths is equivalent to the targets. The report drive *must* at least report
the revision number for those top paths (and report nothing else, if all
children hold the same revision).
> But my instinct is that such a strategy may be nigh-impossible. I'm
> guessing that the RA layer somehow looks at the target list, looks at
> the revision-reporting info, and then manually jumps into the
> filesystem to pull out the data it needs to drive the update editor.
>
> GregS (or others): what's the best algorithm for this? Is Karl's
> dream a possibility? How is ra_dav doing it?
Algorithm? NFC. I haven't applied my brain to it at all. I am hoping to come
up with something that can act in a streamy fashion. That will allow the
client to begin sending data, and the server to begin responding.
Essentially, acting in a full-duplex fashion so that the latency from report
to answer is minimized.
I'm guess that ra_dav will construct a tree from the reported paths, where
each node represents an exception against the parent node. That tree can
then be delivered to the server in XML form, which starts processing it. It
might actually be interesting to "invert" the tree, so that the server can
examine the children, respond, *then* move to the parent. (the alternative
is that the server notes the parents, but must wait for all child reports
first)
The server would open and cache multiple revision trees. If the client
reported files from revisions 5, 8, and 10, and the latest is 12, then the
server will want four trees open. For each file in revision N, it will grab
the node_id to see if it is different from 12's corresponding node_id. If
the same, then no update is needed (other than a rev bump); otherwise, the
client will need to fetch the updated node.
Something along those lines... like I said: I haven't sat down to try it out
yet.
ra_local will have a much easier job because it doesn't have to worrying
about marshalling issues in the same way.
The revision tree cache and some of the server-side processing should be
quite sharable across both RA layers, which means it will be FS
functionality, rather than ra_local or ra_dav/mod_dav_svn functionality.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:21 2006