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

Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-02-26 22:30:08 CET

Branko ÄŒibej <brane@xbc.nu> writes:

> Ben Collins-Sussman wrote:
>
> >With a hash in the auth_baton, runtime data can be 'anonymously'
> >slipped to the correct provider in a discrete manner, provided key
> >namespaces are honored.
> >
> >But it's a bikeshed to me. If people feel strongly, I can make the
> >auth_baton contain the Giant C Structure instead.
> >
> >
> It's *not* a bikeshed at all. Just as in the FS back-end case, using a C
> structure would create dependencies between auth providers. It would
> also make writing custom auth providers that don't live within the
> Subversion code base a royal pain in the butt.

OK, I sort of get it...

It's still a bit confusing, down in the Subversion code there are
calls into the FS/auth layers that eventually make their way into the
custom providers. When these calls are made the Subversion code
cannot be using it's own local context, the fact that the path is
/foo/bar, or that this is a file rename, or whatever, to change the
data supplied to the custom provider. It can't do that because it has
no knowledge of the custom providers. So the data that gets supplied
to the custom provider must simply be a blob of some sort, something
that originated in the application, which does know about the
provider. Why can't that blob simply be passed by the application
directly to the provider when it registers the provider?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 26 22:31:12 2003

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.