> -----Original Message-----
> From: Bob Archer [mailto:bob.arc...@amsi.com]
> Sent: Tuesday, May 21, 2013 10:24 AM
> To: Zé; users@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.
