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