server transactions

Jim,

I spoke with Ben and Karl on the phone this morning, talking about the
walker structures and the DAV code and other stuff like that. Near the end
of the conversation, they had mentioned that you're implementing the FS
layer much closer to the DAV model: open transaction, do operations,
commit/abort transaction (rather than a tree-delta / walker approach).

[ sure, the walker structure will invoke the operations; but the design
  point is a bit different from "before" :-) ]

Anyway... they described it like this (pseudo-code):

    fs = svn_fs_open(...)
    xactn_id = svn_fs_start_xactn(fs)
    
    for each op:
        svn_fs_operation(fs, xactn_id, op)

    svn_fs_commit_xactn(fs, xactn_id)
    svn_fs_close(fs)

This is great, but I'd like to ask for a few clarifications/changes:

1) the xactn_id can be marshalled to disk. it will be used by many processes
   over a "long period of time".

2) corollary: fs_open/close will occur many times for a given xactn:

   fs = svn_fs_open(...)
   xactn_id = svn_fs_start_xactn(fs)
   svn_fs_close(fs)

   save_to_disk(xactn_id)

   for each incoming request (maybe in different processes):
       xactn_id = load_from_disk()

       fs = svn_fs_open(...)
       svn_fs_operation(fs, xactn_id, op)
       svn_fs_close(fs)

   fs = svn_fs_open(...)
   svn_fs_commit_xactn(fs, xactn_id)
   svn_fs_close(fs)

3) I'm okay with a "marshal" function from the fs layer for the xactn_id to
   turn it into an opaque blob of bytes. If the xactn_id is a simple type,
   then I can write it directly. Either way is fine.

4) I'm okay with retaining state associated with the transaction:

     node_id = svn_fs_store_file_contents(fs, ...)
     
     ...
     
     svn_fs_add_file(fs, xactn_id, node_id, parent_dir)

   If the state is retained by the FS layer, then that's okay too.

5) FYI, the pattern will be:

     a) open a transaction
     b) store a bunch of files
     c) store properties on those files
     d) execute a sequence of changes (copy, delete, dirprops?, etc)
     e) commit the transaction

   I am also fine with moving (a) to just before (d). Storing files before
   acquiring a transaction is fine.

FYI:

On the update side of things: the mod_dav_svn module will be operating
mostly by performing a number of smaller queries. "describe the changes for
<this> piece. okay. give me files A, B, and C. now... describe them for
<that> piece. ah. nothing more. thanx!"

This is because I need to get the descriptions of the change *first*. Then,
a second trip is made back to server to fetch those changes.

[ the second trip is the important part: I can't ask the FS layer to stream
  me all of the changes and direct those back at the client. when a file
  needs to be updated, I must use the HTTP GET request. that implies at
  least two trips: one to say it has been updated, then one to grab it. ]

[ actually, I might even be able to arrange to do "send file <foo> to me IFF
  it has been changed since <this> version. but that could be problematic:
  this approach seems to imply a conditional GET for *every* file. fetching
  a summary first is probably much more efficient. ]

Cheers,
-g

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