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

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Friday, May 10, 2013 9:57 AM
> To: Andrew Reedick
> Cc: Branko Čibej; users_at_subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>
> On Fri, May 10, 2013 at 09:40:48AM -0400, Andrew Reedick wrote:
> > It's not a huge problem, but in the real world (i.e. a non-contrived
> > example) I have branches that have been locked and untouched for
> > months that now have a new HEAD revision. And those branches, which
> > are supposed to be walled off from each other until explicitly
> merged,
> > now have a revision in common. (*Every* file and dir in the branches
> > and tags dir trees now has the new, shared rev.)
>
> It is strange behaviour on a conceptual level if you are used to
> thinking in terms of other version control systems (such as ClearCase
> in your case).
>
> However, it is a natural consequence of the way Subversion is currently
> supposed to represent the concepts of versioning files and directories,
> and labels and branches. And it has done so for over a decade. Changing
> this behaviour is far from trivial.
>
> I'm not entirely sure what kind of answer you are hoping to get.
> Are you happy with the answer that Subversion is simply not ClearCase?

I've been using svn since 1.3, so I'm aware of the design limitations. And yes, I would recommend svn over clearcase in most situations.

Anyway, the whole exercise started when I needed a report script to find the common ancestor between two branches and ran into the 'parent dir change false revision' issue. Then I started going through potential edge cases and realized just how fragile svn branches were (where fragile == dependent on human processes and conventions.) Which in turn made me realize just how basic (i.e. bare metal) svn is in regards to "meta-features" such as branching, tagging, baselines, workflows, etc.. It makes me wonder if it would make sense to slap a higher-level interface on top of svn in order to implement the process aspects of version control (and otherwise hide/keep the lower level details/quirks away from users.)
Received on 2013-05-10 17:22:38 CEST