> > .. 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.
True but doesn't the log of ^/projectname1/trunk also change when you commit something to ^/projectname2/trunk ?? Projects aren't isolated within the same repo either.
>
> 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:52:38 CEST