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

> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
> Sent: Tuesday, May 21, 2013 10:24 AM
> To: Zé; users_at_subversion.apache.org
> Subject: RE: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>
>
> .. snip
>
> You keep saying "svn doesn't support branches" yet I use branches every
> day. While there is no way to "list branches" it would be possible. I
> think the current implementation records the parent path in the branch,
> but not vice versa... I assume svn doesn't do this because it would be
> a change to the parent path and the svn design avoids modifying the
> repository on its own.

There are two definitions of branches; svn's definition of a branch (i.e. a dir) and the high-level definition of a branch (theory.) The reason why svn doesn't "support branches" is because a svn branch is just a dir, a dir that is only a branch because it is given special meaning by Humans. Internally, svn doesn't know or care if a dir is a branch or not.

The distinction is important because one of the theoretical benefits of branching is isolation. An outside change shouldn't affect the branch's contents. Unfortunately, changing the parent path of a branch injects a spurious revision into 'svn log' and causes 'svn log --stop-on-copy' to stop early. This is detailed in my original email that started this thread.

So when people say that svn doesn't have branches, they are saying that
a) svn has directory objects, not branch objects, i.e. a svn branch is a branch by human convention only,
b) svn dirs lack the special protections expected of branches (e.g. being isolated from outside change),
c) svn dirs lack the special abilities expected of branches, such as computing ancestry reliably.

Fortunately, in practice, "dirs-as-branches" works fine for the most part and any limitations tend to be minor.

> While there is no way to "list branches" it would be possible.

No-ish. In the average case, "list branches" is easy. Just iteratively run 'log --stop-on-copy'. However, there are edge cases that prevent "list branches" from being deterministic or otherwise make determining ancestry complicated.

For example, is this a rename (to fix a misspelling) or a case where someone combined two steps: 1) creating a new branch and 2) deleting an obsolete branch?
                svn copy branches/ofo-1.0 branches/foo-1.0
                svn rm branches/ofo-1.0
                svn ci
                ... creates revision 100 ...

If I want to find the start of the branch, I run 'svn log --stop-on-copy ^/branches/foo-1.0' which will stop on revision 100. However, svn can't tell me if rev 100 is the start of the branch or whether it's just a spelling fix (in which case I need to run 'svn log --stop-on-copy' again.) Hopefully, the Human who created rev 100 provided a meaningful commit message.
Received on 2013-05-21 17:49:15 CEST