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

> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: Saturday, May 18, 2013 4:17 PM
> To: Zé
> Cc: users_at_subversion.apache.org; David Chapman
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>
> 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?
>

Correct, changing the parent dir of a branch injects a "spurious" log entry in your branches (or tags) sub dirs, which is morally wrong because branches (and tags) should be isolated from outside changes. I documented this in the original post. (Or, given "^/porject1/branches" and "^/porject1/tags", if you "svn copy ^/porject1 ^/project" to fix the naming problem then everything under branches and tags gets the spurious revision. The spurious revision also triggers on --stop-on-copy which needlessly complicates ancestry tracking.

However, given how svn works, I'm not sure that it is technically a technical issue. =) Instead, is it a "branches as first class objects" requirement?

>
> 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.

IMO, it's not a philosophical debate per se, it's a requirements (or expectations) problem. We have two points of view. The first is the low-level technical point of view that is focused on being able to perform any operation at any point in the repository tree. The second is the high-level point of view that needs a VCS to manage baselines, track ancestry, track merges between baselines, etc. IMO, subversion right now is more of a VCS engine than a VCS "system." Basically, it's the trees versus the forest view.

The friction is that the high-level point of view folks are probably your primary customers. For example, when Subversion initially announced that merge tracking wasn't part of the initial architecture, I laughed and blew off svn as a complete waste of time due to intentionally lacking such a basic and essential VCS feature.

Now that svn has implemented merge tracking, tree merging, and the long overdue death of --reintegrate in 1.8, I think it's getting close to the point that svn needs to step back and consider the forest view, e.g. true branches, proper ancestry tracking (instead of --stop-on-copy), etc., in order to maintain relevance. Meaning, svn's paradigm/workflow will need to focus on baselines (aka branches) instead of files and dirs because, in my experience, VCS users are most concerned about slinging baselines around and tracking changes to baselines (i.e. has all work for the release (baseline) been completed, merged, and tested?)

Disclaimer: All IMHO.
Received on 2013-05-21 18:08:10 CEST