On 10.05.2013 15:56, Stefan Sperling wrote: > 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 can understand that having the "Revision" in "svn info" output change on what you expect is a conceptually read-only branch can be confusing. It's also unfortunate that the sort of refactoring mentioned (moving the branch root directory, for example) will disappoint users who expect to use --stop-on-copy for branch point detection. Proper rename tracking should, at least, avoid that issue. Having first-class branches would be nice (I've often said so), but they'd probably have to be implemented as an extension orthogonal to the current versioned-tree model. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com