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

> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> Sent: Friday, May 10, 2013 11:00 AM
> To: Andrew Reedick
> Cc: Branko Čibej; users_at_subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>
> On Fri, May 10, 2013 at 8:40 AM, Andrew Reedick
> <Andrew.Reedick_at_cbeyond.net> wrote:
> >>
> > It's not a huge problem, but in the real world (i.e. a non-contrived
> > example) I have branches that have been locked and untouched for
> > months that now have a new HEAD revision. And those branches, which
> > are supposed to be walled off from each other until explicitly
> merged,
> > now have a revision in common. (*Every* file and dir in the branches
> > and tags dir trees now has the new, shared rev.)
> >
> > I can understand why it happens; svn log needs to know about the
> parent dir rename in order to know (and print) the correct paths for
> subsequent revisions. It's a mostly harmless side effect of copy/mv,
> but it is odd looking and seems sloppy from a purist point of view
> because something outside of the branch is changing the branch's
> history and baseline albeit in a mostly limited fashion.
>
> Isn't this just a difference in subversion's and your thinking about
> the significance of the path change? Subversion is going to see the
> path change affecting everything below it because of the way it holds
> projects together. Is there some reason you are changing a common
> parent path and thinking that it should not affect everything below?
> Is it 'above' what you think of as the actual project?
>

Two words: meta data. A change in meta-data shouldn't change a branch's baseline. Moving "/trunk" to "/project1/trunk" shouldn't change the contents of the trunk baseline. Renaming a misspelled branch (/branches/rle1.0 to /branches/rel1.0) shouldn't change the contents of a branch/baseline.

So, from a technical point of view, where "svn has dirs, not branches," then yes, I would expect a parent dir change to do what it did. From a process/philosophical point of view where branches represent baselines, then I would not expect a parent dir change to do what it did.

Anyway, it represents just one more potential quirk that you have to be aware of when using svn. Fortunately, it's mostly harmless. Long term, once svn's lower level features are mature (true renames, getting rid of --reintegrate, etc..) I would expect a push towards high-level process features such as branches as first class objects.
Received on 2013-05-10 17:44:08 CEST