> On Tue, May 21, 2013 at 9:23 AM, Bob Archer <bob.arc...@amsi.com> wrote: > >>> > >> You are confused. This discussion is about how subversion lacks any > >> support for branching, which is quite obvious to anyone who > >> understands and acknowledges that all subversion does is track revision > changes to a file system. > >> What you are insistingly referring to as branches is nothing more > >> than a copy of a particular subdirectory (i.e., the trunk) into > >> another subdirectory (i.e., branches), which is nothing more than a > >> plain recursive directory copy operation on a file system. The > >> operation doesn't change its name or nature (tag, trunk, simple > >> server-side directory copy) depending on the directories which are copied > around the repository. Is that so hard for you to understand? > > > > > > 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... > > Of course you can 'list branches' as long as you follow and remember _your_ > convention for where they are. You can also delete them to the extent that > they > don't show up in this list (even though they can still be accessed with peg > revision syntax and the actions show in the
True, I can look at the branches folder. However, we keep branches for all revisions in the same branches folder. What I meant is I can't be in a working copy with a repo path of ^/trunk and have it tell me what branches (copies) have been made from that path. Once again, a nice to have, but not a must have... since yes, our naming conventions are sufficient to identify the info we need. > log history of the parent directory). This is nicer in many ways > than just having one special-case 'branch' namespace, especially when you > have many projects in the same repository and/or you like to separate your > release, QA, and experimental branches so different groups don't have to deal > with the clutter from the others. > Subversion doesn't force you to follow good conventions (and I think this > thread > started because someone didn't and the rename of a directory above where > they put a branch was recorded as a change in both the branch and its parent), > but you can if you want. > > > 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. > > Subversion always tracks 'copy from', but not 'copy-to'. In one way > it is correct to say that subversion doesn't have a special concept for > branches, > but it is equally correct to say that every copy is handled like a branch. Right, so this "copy-from" info is exactly what makes the "copy" a "branch" or more than just a file system copy. that's the point I was trying to make. > > -- > Les Mikesell > lesmikes...@gmail.com
