Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

On 09.05.2013 22:08, Andrew Reedick wrote:
> Problem: Subversion doesn't have branches.
>
> Subversion has directory objects, and we Humans(tm) arbitrarily decide that some directories are "branches," thereby giving these directories (branches) magical powers and mystical significance. Meanwhile, Subversion grinds on, treating those magic branches as mundane directories.
>
> You can see the effects of this problem when you change a parent directory common to multiple branches, e.g. changing "/projectFoo/branches" to "/projectBar/branches" will cause every "branch" in "/projectBar/branches/*" to have a shared revision. This complicates finding branch points (--stop-on-copy), finding the common ancestor, etc..
>
> Are there any plans to address this issue or otherwise make branches a first class object? Or at least add a switch to 'svn log' to skip over extraneous "only the parent dir path changed" revisions?
>
> Demonstration:
>
> $ svn mkdir -m "" ^/project1/branches
> Committed revision 73.
> $ svn mkdir -m "" ^/project1/branches/alpha
> Committed revision 74.
> $ svn mkdir -m "" ^/project1/branches/beta
> Committed revision 75.
> $ svn log -q -v ^/project1/branches/alpha
> ------------------------------------------------------------------------
> r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013) | 1 line
> Changed paths:
> A /project1/branches/alpha
> ------------------------------------------------------------------------
> $ svn log -q -v ^/project1/branches/beta
> ------------------------------------------------------------------------
> r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013)
> Changed paths:
> A /project1/branches/beta
> ------------------------------------------------------------------------
>
> As you can see from the svn logs, the "alpha" and "beta" branches are completely independent. They have no revisions in common.
>
> But by renaming the parent "project1" dir to "project100", we create a linkage between the two:
> $ svn mv -m "" ^/project1 ^/project100
> Committed revision 76.
> $ svn log ^/project100/branches/alpha
> ------------------------------------------------------------------------
> r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
> Changed paths:
> D /project1
> A /project100 (from /project1:75)
> ------------------------------------------------------------------------
> r74 | test | 2013-05-09 15:27:49 -0400 (Thu, 09 May 2013)
> Changed paths:
> A /project1/branches/alpha
> ------------------------------------------------------------------------
>
> $ svn log ^/project100/branches/beta
> ------------------------------------------------------------------------
> r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
> Changed paths:
> D /project1
> A /project100 (from /project1:75)
> ------------------------------------------------------------------------
> r75 | test | 2013-05-09 15:27:50 -0400 (Thu, 09 May 2013)
> Changed paths:
> A /project1/branches/beta
> ------------------------------------------------------------------------
>
> Note that the independent branches "alpha" and "beta" now have revision 76 in common... even though neither branch was changed.
>
> Adding insult to injury, "svn log --stop-on-copy" will stop on revision 76, i.e. it treats r76 as a branch point:
>
> $ svn log --stop-on-copy -v ^/project100/branches/alpha
> ------------------------------------------------------------------------
> r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
> Changed paths:
> D /project1
> A /project100 (from /project1:75)
> ------------------------------------------------------------------------
> $ svn log --stop-on-copy -v ^/project100/branches/beta
> ------------------------------------------------------------------------
> r76 | test | 2013-05-09 15:29:11 -0400 (Thu, 09 May 2013)
> Changed paths:
> D /project1
> A /project100 (from /project1:75)
> ------------------------------------------------------------------------
>
> As you can see, the "independent" alpha and beta branches now have revision 76 in common. All because Subversion doesn't have branches.

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.

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.

In the meantime, Subversion 1.8 will go part of the way towards properly
supporting renames: it will track renames in the working copy, with "svn
status" annotating deletes and copies with rename source/target info,
and will, for example, prevent users from committing only half of a
rename. To go the rest of the way, we'll need rename support on the
server side and -- most significantly -- in the merge module.

-- Brane

P.S.: I agree that --stop-on-copy is an awkward UI for branch point
detection; but that's another topic altogether.

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com