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. BTW: an easy way to implement an override would be to require a specific word in the commit message. It's a bit low-tech, but it works pretty well (and you have a nice trace of someone making a conscious decision to override a control). For instance, we have a part of our repository which is an ivy repository (with jars): there we don't want jars to be modified, only added (with a new version number in the filename). In the case a jar still needs to be updated, the magic word "jarupdateallowed" allows it (and this is of course nicely mentioned in the pre-commit error message in case you try it without the magic word). >> The only concrete problem I've read so far (I don't remember if it was >> in this thread or another one) is that copying the parent of all >> branches (or tags) shows up as a revision when you "svn log" the >> branch. So okay, that's one thing. Any others? > > The good old "'svn commit file; svn log' doesn't show the commit to > file" issue? Sorry? What issue is that? I'm talking about the fact that 'svn mv ^/branches ^/twigs' will show up in 'svn log ^/twigs/branchX' for every branch (which looks like a sort of cross-branch commit then). I don't find this a big deal either. But like so many things, it will probably bother someone. -- Johan