Re: update processing

On Thu, Dec 14, 2000 at 09:38:48AM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>
> > b) We send one big mother request about the client state.
> >
> > This corresponds to the "close_edit" strategy that Ben mentions in
> > svn_ra.h.
>
> Indeed, this is the only real thing we can do, and it's a big "hunka"
> server work, as you said. Specifically, it's a big hunka filesystem
> work.
>
> The client sends a tree-delta devoid of text-deltas; this tree-delta
> gives a root revision #, and then "replaces" any file or dir which is
> at a *different* revision #.
>
> The filesystem then builds a mini-node-tree, floating in space, which
> is a model of the working copy. The filesystem then compares this
> tree to the "head" tree, and sends back a custom tree-delta.
>
> Does everyone agree on this model now?

Nope :-)

The body isn't a "tree delta" and pretending it is some variant does a
disservice. The body is simply reporting local state, not a difference. The
request is going to be a WebDAV REPORT request, and we should try to make it
as generic as possible. Hell, it is already going to lock the client and
server together :-(, so I'd rather not code it too strongly to SVN.

The request is going to look something like:

REPORT /repos/myproj HTTP/1.1
Host: www.lyra.org
Content-Type: text/xml; charset="utf-8"
Transfer-Encoding: chunked

<?xml version="1.0" encoding="utf-8"?>
<update-status-report xmlns="http://subversion..." xmlns:D="DAV:">
  <directory name="/" ver="8">
    <file name="foo.c" ver="7"/>
    <file name="bar.h" ver="7"/>
    <directory name="subdir" ver="8">
      <file name="baz.c" ver="6"/>
      <directory name="sub2" ver="7">
      </directory>
    </directory>
  </directory>
</update-status-report>

After pondering on the problem today (while running errands and whatnot),
the server isn't going to have too hard of a time to figure out what is
going on. Recall that server doesn't need to come up with diffs while
processing the REPORT (because the changes need to be fetched separately
using GET and PROPFIND methods). It only needs to resolve each resource as
being in one of three states:

1) the client has the latest revision of the resource
2) the client has an older revision, but no actual changes were made between
   the older revision and the latest
3) the client has an older revision and must fetch some changes

[ where changes can be content or properties ]

For each resource, mod_dav_svn (or a utility function in FS) will do:

Step 1: if the client revision == latest revision, then the resource is in
        state #1 (and stop)

Step 2: fetch the node ID for the client's file/revision, and fetch the node
        ID for the latest file/revision.

Step 3: if the node IDs are the same, the resource is in state #2;
        else it is in state #3

These states are reported back to the client, along with the necessary URLs
for fetching updates.

Step (2) could be simplified if the client supplies the node ID in the
request (that it stored/cached at fetch time). That means the server only
needs to open the "latest" revision tree to look up node IDs.

The client receives the report and does one of three things, according to
the state of the resource:

1) do nothing
2) record the new version URL, but don't fetch anything
3) fetch new content and/or properties [the report will probably want to
   indicate, in some way, which or both of these aspects to fetch]

Note that the report may contain information about resources that weren't in
the original request. In the example above, "/" is an older revision and
(implicitly) its contained files are older, too (unless otherwise
specified). The REPORT response will contain information about each of those
contained files.

[ oh. there will need to be some kind of response state that says "that
  resource was deleted". dunno if "add" is anything beyond reporting a
  resource that the client hasn't seen before. ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/