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

> On 05/13/2013 10:04 AM, Bob Archer wrote:
> > What I don't understand is why someone argues about how git does
> > something is better yet uses svn. Use the tool that works for you, or
> > works the way you expect a tool to work.
>
> Oh, I'm sure if we tried we could all think up plenty of reasons why someone
> might argue the superiority of one tool over another and yet use "the other".
> Perhaps the superiority isn't universal -- only some features are better, while
> some lack. Perhaps the choice of tool isn't available for one reason or another.
> Whatever. It hardly matters here -- on this list -- why someone who likes Git
> also uses Subversion.
>
> What matters is the desired outcome of the discussion. This list is about
> Subversion. OtherVCSystem fanboyism isn't welcome here, not because it's
> fanboyism (which is just intellectually pathetic) but because it's off-topic. But
> merely pointing out things that Git does better (in someone's approximation)
> than Subversion isn't necessarily fanboyism. And if the point of comparing
> Subversion to Git or Hg or OtherVCSystem is to find ways to make Subversion a
> better product, that's completely on-topic and welcome (so long as the
> discussion is handled maturely).

Yes, I get what you are saying. But, to claim the way svn supports branches and tags is a "hack" doesn't seem like a productive conversation. It is far from a hack and that statement dismisses all the hard work of design and implementation that went into svn almost dismissing the whole team many of which are volunteers.

It would be nice if branches could become a first class object with the branch command being very specific. But, what we have is far from a hack if you understand how it works.

I would like to see more "first class" support for projects and/or defining a project root. For example, perhaps there can be an svn:projectroot property that must be on a folder and the branch/merge command will only work on project roots. If that is done of course the maintain backward compatibility there could be a switch in the client config to allow for bypassing this requirement, or perhaps the --force switch could do it. Also, a property can be place on a branch so that tooling can know it is actually a semantic branch rather than just a fork (copy).
Received on 2013-05-13 17:21:48 CEST