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