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.
> 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
> promulgating.
You've missed the point. It's irrelevant if some development branches
last for ages. The point is that when a SCM system does support
branching, it doesn't matter if you organize your workflow based on
development branches that last for ages or are only transient, because
that SCM system does offer support for both of those approaches. With
subversion, as it doesn't support branching, then you are only able to
simulate them by making copies of the trunk and moving them around your
repository, and although that approach doesn't cause any major problems
if all your branches will be eternally worked on, it becomes a problem
with transient branches such as those which are used in the feature
branches approach.
> 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.
I've been saying that from the start, and I've received some unfortunate
replies for doing so.
> 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.
That isn't being disputed. What has been stated, and stated repeatedly,
is that it would be even better if subversion actually offered support
for branches.
> 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.
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?
--
Zé
Received on 2013-05-18 21:02:15 CEST