On Dec 9, 2004, at 8:52 PM, Branko Čibej wrote:
>>
> Oy, wait a minute. I thought the expiration date was there only to
> support generic DAV clients, and that our client should know nothing
> about it. So why store it in the WC?
>
The svn_lock_t structure is defined in svn_types.h, available to every
library on both sides of the network, and is totally transparent.
We agreed that svn clients wouldn't ever have a UI (or API) to *set*
expiration dates -- that 'svn lock' would always create a non-expiring
lock. Only mod_dav_svn would allow generic DAV clients to set
expiration times.
Still, I don't see why would should "hide" the expiration_time field of
an svn_lock_t from anyone. It's still an important piece of
information, even if not every client can set the value. (For example,
if I run a client command to list all locks in the repository, I would
know that any locks with non-zero expiration time were created by DAV
clients.)
>> + When the commit is finished, if the user didn't
>> specify
>> + the --keep-locks option, the client will issue unlock
>> + commans for the files it has locked. (### Is it
>> + cleaner to have a new ra->get_commit_editor2() with a
>> + flag for this and tlet the server take care of it. It
>> + will avoid a lot of network round-trips in ra_svn,
>> + since the server already got the tokens.)
>>
> I think the server should clean up in this case. Apart from avoiding
> network round trips, it helps to make the whole thing atomic. It would
> be a bit funny if the commit succeeded, but a subsequent unlock
> errored out because someone happened to break the lock in the
> meantime.
Oh jeez. So we're talking about create svn_fs_commit_txn2() now, which
takes a "free/keep locks" boolean?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 10 19:08:38 2004