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

Re: svn commit: r12093 - branches/locking/subversion/mod_dav_svn

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-12-01 17:32:31 CET

Ben Collins-Sussman wrote:

> On Nov 30, 2004, at 8:39 PM, Branko Čibej wrote:
>> sussman@tigris.org wrote:
>>> Author: sussman
>>> Date: Mon Nov 29 22:03:52 2004
>>> New Revision: 12093
>>> + /* Generate a UUID. */
>>> + /* ### perhaps this should be a func in libsvn_fs.so, shared by
>>> + mod_dav_svn and both fs back-ends?? */
>>> + apr_uuid_get (&uuid);
>>> + apr_uuid_format (uuid_str, &uuid);
>>> + token->uuid_str = uuid_str;
>>> + dlock->locktoken = token;
>> I think it's pretty much obvious that lock all lock token management
>> function should live in libsvn_fs, not in mod_dav_svn. What we have
>> here is a layering violation.
> Well, here's the problem:
> 1. libsvn_fs_base needs to generate lock-token UUIDs.
> 2. libsvn_fs_fs needs to generate lock-token UUIDs.
> 3. mod_dav_svn needs to generate lock-token UUIDs.

All of the above are wrong, because these modules need lock tokens, not
lock token UUIDs.

> At the moment, this is nothing more than calling apr_uuid_get(). But
> maybe we'll want to change that someday, make it fancier, use the
> repos UUID + counter, whatever. So a shared routine would be nice.
> We could certainly make a function in libsvn_fs to do this; but then
> wouldn't it be a layering violation for fs_base or fs_fs to "call up"
> into the fs dispatch library?

No, why? They don't call up into the fs dispatch library, they call into
a fs utilities library. Which doesn't have to be in a separate shared
lib, of course, it can live in libsvn_fs, which happens to be the only
part of the FS layer that implements a public API that other modules can
use. It seems the logical place.

(n.b.: I don't see the term "layering" to mean "calls go only from
higher to lower layers" -- callbacks do exactly the reverse. And you can
look at the fs_util module as a different logical entity that lives side
by side with fs, fs_fs, fs_base and mod_dav_svn -- but just happens to
physically sit in libsvn_fs.)

Ah yes Unless circular dependencies are a problem, in which case we'd
need a separate shared lib anyway. They might be on Windows, who knows...

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 1 17:37:39 2004

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