Johan Corveleyn wrote on Sat, May 18, 2013 at 23:38:11 +0200:
> On Sat, May 18, 2013 at 11:15 PM, Andreas Krey <a.krey_at_gmx.de> wrote:
> > On Sat, 18 May 2013 22:16:48 +0000, Johan Corveleyn wrote:
> > ...
> >> Please be concrete, and give examples of what really bothers you as a
> >> user or an admin in your daily work. Saying that "branches are not
> >> first class", or "I don't like it that Subversion implements
> >> branches/tags by copying directories" are too abstract, and really not
> >> relevant. Why should I care how SVN implements its branches
> >> internally, as long as it works for the use cases I need?
> >
> > It doesn't. Write protectings tags is obviously a pain in the ass;
> > <anecdotal>the admins of 'my' production repo still didn't manage to
> > disallow additions to tag directories</evidence>, and googling for the
> > problem doesn't even turn up any hints that are within the subversion
> > project pages. Let alone provide an easy way for users to override
> > that (like adding -f).
>
> Okay, that's another concrete example (built-in support for
> write-protecting tags), thanks.
>
> Personally, I don't find this to be a big deal. I use a (perl)
> pre-commit hook that was once posted to this list for protecting tags.
> Also, if someone makes a mistake, and the pre-commit hook would
> somehow not catch it, I'll see it in my post-commit mails, and can
> easily correct the problem.
>
> But I agree that built-in support for this would be much better. It's
> one of those little things that can add up (if you have to set it up
> all yourself with hooks), especially in large installations.
One way this could be implemented is by introducing more fine-grained
ACLs in authz files than the current ""/"r"/"rw" scheme.
(i.e., in the "To get a feature in the core, have a design thread on
dev@ and then someone implements the agreed-upon design" process, the
above is one potential design.)
Received on 2013-05-19 05:02:43 CEST