[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 12:33:44 -0700

On 5/18/2013 12:01 PM, Zé wrote:
> On 05/18/2013 07:16 PM, David Chapman wrote:
>> You are pretty insistent that there is One True Way to use branches in
>> development.
> No, I'm stating that if all a SCM does is track changes made to the
> contents of a directory and you rely on changes made to that directory
> to emulate branches, then there are some significant downsides to this
> approach when compared with SCM systems which do offer support for
> branching.

You've missed the point. You have a specific definition of branching
and do not believe that anything else can be called branching. In your
message to Thorsten Schöning, you said that branch history should be
deleted if the branch is deleted. That is fundamentally in opposition
to the definition of Subversion, which is meant to retain all of a
project's history. People ask for an "obliterate" feature all the time
after committing a file with private information, e.g. passwords. That
is hard by design within Subversion, and most of its users are glad. I,
for one, would object strenuously if the history of a branch were
deleted just because it was never merged into trunk. In my business
(Electronic Design Automation), knowing what doesn't work (and why) is
often just as important as knowing what does work.

> As you may understand, not everyone has a lot of time to spend on side
> projects, and when they do then there's the problem of attaining the
> insight and technical know-how to do so.
> In spite of that, I don't believe that not being able to spend time
> contributing to a project justifies declaring a specific suggestion to
> be tabu. Forbidding anyone from, or attacking them for mentioning a
> downside or a shortcoming doesn't make it go away, and doesn't make
> the project any better than what it already is. What does contribute
> to its improvement is providing suggestions on ways to improve it,
> such as suggesting that implementing a sorely missed feature would be
> a significant improvement. Do you agree?

As I said, you have a specific definition of branching and are insisting
that it is the only valid definition even though it would require a
fundamental revision of Subversion's data model. You are insisting that
branching be implemented your way even though others disagree. This is
not helpful.

Saying "+1 for branches as a first class object" is helpful because it
allows developers to prioritize their donated time, and to choose a
definition and implementation that balance features vs. implementation
complexity. But unless you are willing to dig into the internals of
Subversion and understand how it is used, insisting on a particular
definition and implementation is not helpful.

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