[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r12241 - trunk/notes/locking

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-12-10 18:55:50 CET

Ben Collins-Sussman wrote:

> 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.)


>>> + 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.
> + When the commit is finished, if the user didn't specify
> Oh jeez. So we're talking about create svn_fs_commit_txn2() now,
> which takes a "free/keep locks" boolean?

I dunno, but if that's what it takes, I think it's not unreasonable.
You've been munging the FS vtables anyway, haven't you?

-- Brane

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:20:19 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.