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
Received on 2013-05-10 16:11:16 CEST