> -----Original Message----- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: Thursday, May 09, 2013 4:35 PM > To: users@subversion.apache.org > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > > Well, given that you have not created any branches, this works as > expected :) There are no branch points in your repository; only > directories. A branch is created by copying a directory (with "svn > copy"), not by creating it (with "svn mkdir"), and that is why your -- > stop-on-copy works the way it does -- the only copy is a side effect of > the rename (which is currently represented as copy+delete), hence -- > stop-on-copy stops ... when it sees the copy.
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 > atomic operations. This is indeed being addressed, but a complete > solution will take time. I'm not going to go into technical details > here; if you're interested, you're welcome to join the dev@ list and > listen in (or participate) in the discussions there. 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.
