RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
From: Andrew Reedick <Andrew.Reedick_at_cbeyond.net>
Date: Fri, 10 May 2013 09:40:48 -0400
> -----Original Message-----
No, the effect is the same whether you use 'svn mkdir', 'svn copy', or 'svn mv', for single dirs or for trees full of files and subdirs. If you change the name or path of a parent dir, you implicitly create a common revision across each and every subdir and file. If you "svn mv ^/tag ^/tags" or "svn mv ^/branches ^/project1/branches" then everything under /tags or /project1/branches will now have a new, common, revision according to 'svn log'.
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.)
I can understand why it happens; svn log needs to know about the parent dir rename in order to know (and print) the correct paths for subsequent revisions. It's a mostly harmless side effect of copy/mv, but it is odd looking and seems sloppy from a purist point of view because something outside of the branch is changing the branch's history and baseline albeit in a mostly limited fashion.
Anyway, if you never restructure your high-level tags/branches/trunk dir structure and if you never rename a branch or tag, then you won't see this problem.
> The real problem here is that Subversion does not treat /renames/ as
Yeah, I'm aware of the rename issue (I have a background in ClearCase,) but the 'lack of branches' is a whole issue in and of itself. A branch really should be a walled off garden until you explicitly merge.
This is an archived mail posted to the Subversion Users mailing list.