[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 03:52:29 CET

lundblad@tigris.org wrote:

>Author: lundblad
>Date: Wed Dec 8 08:44:45 2004
>New Revision: 12241

>+ libsvn_wc also stores the other fields of a lock (owner, comment,
>+ creation-date, expiration-date) in the entries file, so that
>+ they are available for the info command. Note that this
>+ information is only stored if the current WC has a lock on
>+ the file.
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?

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

> c. Breaking a lock
>+ svn unlock --force will first ask the server for a lock
>+ token and use it in the ra->unlock command to break the
>+ lock.
Should look in the WC first if the lock token is there... maybe. This is
a small optimisation for people who break their own locks. :-)

-- 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 03:53:42 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.