[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Tue, 21 May 2013 15:48:54 +0000

> On Tue, May 21, 2013 at 9:23 AM, Bob Archer <Bob.Archer_at_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
> lesmikesell_at_gmail.com
Received on 2013-05-21 17:49:28 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.