On Wed, Jul 18, 2012 at 1:13 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> 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.
I'd be interested in hearing more about how you envision first-class branches.
I guess that would require more fundamental work accross the board
(FS, server, protocol, client). But regardless (and ignoring for a
minute how hard it would be to migrate existing repositories), I'd be
interested in hearing more details of how this could fit into
Subversion conceptually. That way, we could have more of an informed
discussion considering the various options.
Concerning migration, I think there would be roughly 3 options:
1) 1st class branches introduce new stuff in SVN that make in not
backward compatible with current repositories -> hence 2.0
2) 1st class branches can be made interoperable with 1.x, but we don't
migrate anything -> you can use the feature for any new branches you
create
3) 1st class branches can be made interoperable with 1.x, but we offer
a way to migrate existing branches
> 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.
Another interesting thing (also suggested by Julian [1]) would be that
branches should not only be identified as branches, but also
identified as part of a certain context, project, branch namespace or
whatever you want to call it. So users can create more structure in
their branches (and only merge between branches of the same
branching-space), similar to how they can now order branches in
directories under ^/branches, but then in a clearly specified way (and
usable to enforce certain things, for merging for example).
That is not addressed by the proposal that started this thread. But
then again, I don't know how important that kind of structure would
be, or if it would be used much in practice (there is probably a lot
more to be discussed before diving into something like this ... a
topic for another thread I guess).
[1] http://svn.haxx.se/dev/archive-2011-10/0406.shtml
--
Johan
Received on 2012-07-18 16:50:54 CEST