Proposal for branching policy towards KF5

[Ben Cooksley]

On Sun, Jul 21, 2013 at 9:13 PM, Thomas Lübking
<thomas.luebking at gmail.com> wrote:
> On Sonntag, 21. Juli 2013 05:04:10 CEST, Michael Pyne wrote:
>>
>> On Fri, July 19, 2013 00:21:21 David Faure wrote:
>>>
>>> After more live discussion with Sebas and Marco plus Aaron over a video
>>> chat, we came up with the following setup for the workspace repos (*) :
>>>
>>> Adding a similar generic selection for qt5/kf5, we would end up giving 3
>>> options to people who compile from sources: stable, latest-qt4, or
>>> qt5/kf5-
>>> based. ...
>>
>>
>>> <implementation>
>>> Michael: I see two ways this could be done in kdesrc-build. Either with
>>> the
>>> selection layers being defined by the projects XML and some additional
>>> magic
>>> in branch selection to allow for these new names, or with a much more
>>> low-tech solution: 3 available files to include from kdesrc-buildrc, like
>>> ...
>>
>>
>> Well there's a 3rd method as well, which is to add a separate metadata
>> file to the kde-build-metadata repository which maps each git repository to
>> its appropriate branch for each of the 3 categories.
>
>
>
> git symbolic-ref refs/heads/NEXT refs/heads/master
> or for workspace/libs
> git symbolic-ref refs/heads/NEXT refs/heads/KDE/4.11
>
> eventually also
> git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.11
>
> and then at some point
> git symbolic-ref --delete refs/heads/CURRENT
> git symbolic-ref refs/heads/CURRENT refs/heads/KDE/4.12

It would appear that "git remote update" does not handle symbolic refs
at all (at least it does not handle HEAD) so that will require manual
updates on both the main Git server and then each anongit node - for
each change we make.

>
> But i don't know how this will exactly behave on remote/local conditions
> (ie. whether you get a local symref if the remote is one)
>
> Cheers,
> Thomas

Thanks,
Ben