[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Standardizing a 'svn:branch' (boolean) property

From: Branko Čibej <brane_at_wandisco.com>
Date: Wed, 18 Jul 2012 01:13:34 +0200

On 17.07.2012 22:55, Julian Foad wrote:
> Branko Čibej wrote:
>> On 17.07.2012 21:08, Julian Foad wrote:
>>> I know it would be nice and convenient if it was defined centrally
>>> here, but ... I dunno, others may disagree, but I think we need a much
>>> more rigorous definition before I'd be happy to consider it.
>> Thank you, Julian, for putting it so clearly.
> Yeah, well, it seems some people -- cmpilato for one -- do have some non-shallow thoughts about this subject. C-Mike said on IRC:
> julianf: I think you're looking at things backward. Or maybe I am. I don't want users' haphazard behaviors to inform the server about what appears to be a branch-root. I want a person -- the same person who would fire off the angry email to the idiot that merged and committed a subtree -- to say up front: "Here's our branch-root, server (and client). Now protect it!"
> I guess what I want is Enversion semantics, implement in Subversion's core with prelim enforcement in the client (as opposed to in a hook script that can only fire after users upload 50Meg of ill-aimed merge commit info).

I think there are two ways of approaching this problem: one is to
consciously break backwards compatibility, introduce first-class
branches in a separate namespace from the tree, and only allow merging
between branches. This would simplify the data model enormously, but I'm
not sure it's even possible to create a sane migration tool from the
current data model to this one.

The other way, which you propose, I'm still trying to understand the
reasons for. I'm very much guessing that they can be grouped as follows:

 1. Disallow the kinds of branches and consequently merges that
    currently do not work correctly;
 2. Simplify branch identification for users
 3. Simplify merge commands

Of the above, I can empathise with points 2 and 3. But point 1 should be
solved without introducing this new feature. I'm not saying it's going
to be trivial, and I won't hijack this thread by going into details.

-- Brane

Certified & Supported Apache Subversion Downloads:
Received on 2012-07-18 01:14:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.