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

On Sat, May 18, 2013 at 9:33 PM, David Chapman <dcchapman_at_acm.org> wrote:
> 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.

Let's take a step back. What was the actual problem that lead to this
discussion?

Zé, I fully agree that suggesting ways for improvement, and generally
participating in discussions with users and devs, are very valuable
ways of contributing. In fact, participating in the mailing lists is
the first item mentioned on the "Getting involved" page [1].

However, this discussion lacks focus, it sounds more like a
philosophical debate, with large ideas being thrown against each
other. If you want to get anything useful out of this discussion (be
it planting the seeds for improvements to Subversion, or be it a
deeper understanding for yourself of how to work effectively with
svn), you'll have to get much more concrete.

So what's the actual problem (or problems) with SVN's branching and
tagging? Where does it hurt your workflow? What would make SVN not
"hurt you" in that way?

Please be concrete, and give examples of what really bothers you as a
user or an admin in your daily work. Saying that "branches are not
first class", or "I don't like it that Subversion implements
branches/tags by copying directories" are too abstract, and really not
relevant. Why should I care how SVN implements its branches
internally, as long as it works for the use cases I need?

The only concrete problem I've read so far (I don't remember if it was
in this thread or another one) is that copying the parent of all
branches (or tags) shows up as a revision when you "svn log" the
branch. So okay, that's one thing. Any others?

[1] http://subversion.apache.org/contributing.html

--
Johan