Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

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.

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