You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2004/12/10 02:35:39 UTC

Re: svn commit: r12233 - in trunk: doc/book notes/locking

sussman@tigris.org wrote:

>Author: sussman
>Date: Tue Dec  7 16:51:45 2004
>New Revision: 12233
>
>Modified:
>   trunk/doc/book/TODO
>   trunk/notes/locking/locking-implementation.txt
>Log:
>
>* notes/locking/locking-implementation.txt:
>         add some client-side designs, after a bunch of IRC discussion
>         with lundblad and ghudson.  Please comment!
>  
>

>       2. New client subcommands
>           
>          a. Creating a lock
> 
>+             'svn lock' calls new RA->lock() function, which marshalls
>  
>
I think it's "marshals", not "marshalls"

>+             BASE rev of file to svn_fs_lock().  FS does a
>+             complimentary out-of-dateness check before creating the
>+             lock.  Lock token is marshalled back to client, stored in
>+             .svn/entries file.
>+
>          b. Using a lock
> 
>             1. Using a lock to Commit
> 
>+               When driving the RA layer's commit editor, the client
>+               pushes tokens by doing an editor->change_file_prop() of
>+               svn:wc:entry:locktoken.  (Exactly the reverse of the
>+               way the client -recieves- entryprops.)  The RA editor
>+               parses the entryprop, then marshalls the token however
>+               it wishes over the network:
>+
>+                  - for ra_svn, probably just a new argument in the tuple.
>  
>
This can be done in a backward -compatible way, I expect?

-- Brane



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org