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

Re: ra_dav->unlock()

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-01-07 18:41:11 CET

On Fri, 2005-01-07 at 08:38, Ben Collins-Sussman wrote:
> Looking over the two mod_dav_svn vtable funcs (dav_svn_refresh_locks()
> and dav_svn_find_lock())... they *could* be reimplemented to call
> _lock_from_path() instead of _lock_from_token() if we really wanted
> that. IOW, if we wanted to delete the _lock_from_token() API from
> svn_fs.h altogether, we'd be just fine. I don't think there are any
> other callers. But as a matter of completeness, it seems odd for our
> fs locking API to return tokens that "represent locks", and yet not
> have an API to lookup by token.

I'm strongly in favor of removing _lock_from_token. My arguments:

  * As Mike points out, there's nothing wrong with conceiving of a lock
token as "representing" a lock in the sense of identifying it, rather
than being a lookup token for it. Put more obscurely: it's a way of
binding a lock on a pathname to a particular working copy, not a way of
naming the lock.

  * One's conceptual model shouldn't lead to implementing unnecessary
infrastructure. A token -> lock lookup table is a significant amount of
extra code, and potentially a significant amount of extra space used in
a repository, for no present benefit to the user.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 7 18:42:22 2005

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.