[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: David Chapman <dcchapman_at_acm.org>
Date: Sat, 18 May 2013 11:16:11 -0700

On 5/18/2013 9:37 AM, Zé wrote:
> On 05/15/2013 06:59 PM, Les Mikesell wrote:
>> On Wed, May 15, 2013 at 12:06 PM, Andrew Reedick
>> <Andrew.Reedick_at_cbeyond.net> wrote:
>>> Plus, telling people not use to svn's touted directory manipulation
>>> features because of side-effects is a bit self-defeating.
>> Not if you want it to act like SCM's that have branches that don't
>> allow such things.
> Don't you understand that *that's precisely the problem*? Currently,
> subversion does not support branching, and it's only possible to
> manipulate subversion to *act* like it does by copying around
> subdirectories in the repository, and in the process screw up with the
> repo's revision history.

You are pretty insistent that there is One True Way to use branches in
development. A lot of people do not agree with you. I've seen branches
used as long-term development vehicles (think years), with only
cherry-picked merges coming in from or going back to trunk. This does
not match the definition of "use once and discard" that you are

Subversion was designed as a versioned file system, in response to the
shortcomings of CVS; concepts like branching and tagging have always
been naming conventions built on top of that (later, merge tracking was
added to assist branching). If you go back and look at the archives of
this list, you will see this quite clearly. "trunk", "branches", and
"tags" are simply naming conventions. People don't even need to follow
those, as has been noted time and again. This gives people a lot of
flexibility, which they quite naturally use.

And yes, ordinary file systems do support branching and tagging. I've
seen it done. It's expensive, but it works.

If you want Subversion to be extended in a particular way, learn its
internals and write a spec which comprehends the internals and current
usage. Maybe then someone will be inclined to work on it. Better yet,
offer help. This is a community project, after all, and what better way
to be a member of the community than to help? Right now you are not.

     David Chapman      dcchapman_at_acm.org
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
Received on 2013-05-18 20:16:57 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.