> -----Original Message----- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: Friday, May 10, 2013 9:57 AM > To: Andrew Reedick > Cc: Branko Čibej; users@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.)
