> > .. 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. > > >
