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.k...@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.)
