[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-12-10 18:39:23 CET

On Fri, 10 Dec 2004, [UTF-8] Branko ─^Libej wrote:

> 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?
>

Good point. It is always optional, so if we want to add it later, that's
no problem. I'll drop it if no one objects.

> >+ 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.
>
Yes. That was changed later and the new APIs reflect that. It will not be
done atomically on the server, but that's no problem, since we can just
ignore not locked errors. That's a non-error in this situation.

> >+ 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. :-)
>
And a pesimization when the lock token is defunct, in which case we need
to unlock, get-lock, unlock. Breaking ones own valid lock should be rare.
Thanks,
//Peter

---------------------------------------------------------------------
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:07:44 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.