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é
