Re: subversion authz wildcard

On Thu, Mar 31, 2011 at 2:25 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Mar 30, 2011 at 09:43:27PM -0700, Michael Mac (Palm GBU) wrote:
>> Hi,
>>
>> I'd to query the user community to know if there's been any progress
>> in using wildcards with authz? Is there a work around for this? There
>> was previous mentioned that version 1.7 may have this feature
>> enhancement, but not a guarantee.
>
> See http://subversion.tigris.org/issues/show_bug.cgi?id=2662
> You can add yourself to the Cc list there to get progress information
> via email.
>
> I took a look at one of the patch submissions we've received for this.
> Unfortunately, it didn't qualify, see
> http://subversion.tigris.org/issues/show_bug.cgi?id=2662#desc20
> If we decide to disallow leading wildcard characters, though,
> that patch would work.

I personally think we can live without leading wildcards, as long as
wildcards in the middle would work. Those would be the most useful
IMHO, to allow entries such as:

    /branches/*/secretfolder

    /privateproject/tags/*/public

I.e. to give a certain folder under all branches/tags a set of
specific permissions. (question: would such a * match a single
directory level, or any substring of the path (arbitrary directory
depth)?)

From my point of view, applying a special set of permissions to a
certain subfolder everywhere in the repository, would not be a "must
have". Normally, you either have a TTB structure at the root, so you
can specify things specifically for T, T and B. Otherwise there are
usually multiple projects at the root, and I think usually the
permissions will not be universal over all the projects.

Unless maybe to make "tags" read-only everywhere, but AFAIK you need
to make it not read-only, but "add-only", and that's not possible with
authz (it's possible with pre-commit hooks).

But YMMV ... maybe someone else has another use-case in mind?

> There is another patch submission, against an old version of Subversion.
> The approach it is taking seems to be workable.
> However, applying this patch on top of trunk is a huge chunk of work.
> We'll also need to find out whether it's actually usable in practice,
> since it needs to crawl a lot of paths in a repository in case of
> wildcards such as */tags (as explained in the issue).
> So while it might work, performance might turn out to be dismal
> for large repositories.

Hm, if the performance of this approach is not up to par (or at least
a serious risk), maybe the other patch is preferable? That is, if we
can live with the "no-leading-wildcards" limitation ...

Cheers,

-- 
Johan