> -----Original Message----- > From: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Wednesday, May 15, 2013 11:05 AM > To: Zé > Cc: Subversion > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > On Tue, May 14, 2013 at 3:33 PM, Zé <jose.pas...@gmx.com> wrote: > >> > > What has been said regarding > > subversions lack of support for branching was, I think, quite clear. > > Well, no. The only thing you've made clear is that you don't like it > or you don't understand how it is supposed to be used. You have not > explained why you lay your projects out so that you need to move the > parent directories of your project around after creating branches. > Nor have you made any real suggestions about how it might be improved > in a way that doesn't break the ability to copy and subsequently merge > any arbitrary subdirectory which is clearly a feature even though it > doesn't mesh well with your concept of only having one way to branch. >
Isolating change is a fundamental tenet behind branching. The fact that an "outside" change can affect a branch (and a tagged baseline) is wrong by definition. Telling folks to never change their branching structure is a bit short-sighted given the lack of reliable precognitive ability in general and that occasionally folks like to clean up the branches and tags dir when they're cluttered with dozens of old branches and tags. Telling folks not to run 'svn mv tags/1.0* archive/' simply isn't helpful. Plus, telling people not use to svn's touted directory manipulation features because of side-effects is a bit self-defeating. As for the various CVS comments in the thread, no one cares if Subversion was originally meant to be a better CVS. Building a better CVS is akin to saying "let's build a better Model-T". Personally, when it was announced that svn wouldn't include merge tracking, I wrote off SVN as useless for not including the basics. Fortunately, merge-tracking and merging have come a long way since then and I, for one, am looking forward to 1.8 driving a stake in --reintegrate. Furthermore, Subversion's vision statement is: "Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations." In the Future(tm), Subversion, IMHO, will need to treat branches (and tags) as first class objects because branches and tags are core concepts of modern version control systems. To re-emphasize my point, isolated branches are an expected, fundamental, expected, and/or part of a minimal set of features that any VCS must support. So please, no more references to "svn being a better CVS". It's a very limiting and short-sighted thing to say. Fortunately, the "parent dir changes affect branch history" problem is a minor hiccup. There's no need to grab torches and pitchforks and rush to implement formal branches right now. It's just something that needs to be kept in the back of people's minds once the merging, tree merging, and true renames are implemented and are mature. I think that most folks can live with a spurious revision appearing in 'svn log' entry after a parent dir change.
