update processing

I posited the other day, that the comments in svn_ra.h about a "two step"
update process were probably incorrect -- that we should be able to
streamily send "current state" to the server and perform the update/fetch at
the same time. (rather than wait for close_edit from the current state
processing)

After some pondering... nope. I'm quite wrong on that one.

The simplest test case is a directory at v5. On the server, it is v6. When
we send the directory info to the server, what should the server do?

*) It can certainly say "the directory is out of date, so fetch it"

*) It can't say anything about the contained files. The server doesn't know
   if we're about to sending state info saying that all the files are at v6,
   or possibly some mix of v5/v6 files.

*) The contained files can only be reported when a "close directory" occurs.
   Depending on the communication between the client and server, this event
   may or may not be transmitted:

   a) We send multiple requests to the server about each of the pieces of
      state on the client.

      Given HTTP's stateless nature, this implies that we cannot have a "dir
      open" and "dir close" pair of methods. Therefore, no "close dir" ever
      occurs in this model.

   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.

Model (a) has some serious problems. If we are sending information requests
only for a subset of the working copy (e.g. Dir1 is v5, File5 is v6, but we
say nothing about File1..4 because they are also v5), then how do we get the
proper info for File1..4? Each request (dir or file) has one of three
responses:

  1) the file/dir is up to date
  2) the file/dir is an older revision, but the latest revision is exactly
     the same (update the metadata, but not the content)
  3) the file/dir is an older revision and needs to be updated

What model (a) boils down to is sending a PROPFIND request for each
directory in the working copy. The PROPFIND would report on the current
state of each child, and the client would then sort out what to do.

There is no specific DAV mechanism for model (b), although we can easily use
a Subversion-specific "report" to do this. The server will have much more
work because it is going to need to sort out the Mother Request and report
on all the updates. There is also a latency issue: we must wait until the
client has generated the complete request, and the server must generate the
report containing the update info. (the client then issues additional
requests to fetch content/properties)

Model (a) is similar to the checkout process (a series of PROPFINDs followed
by GETs). Model (b) is a big hunka hunka server work.

Cheers,
-g

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