KDevelop 4.3 branch screwed again?

Fri Jun 22 20:52:08 UTC 2012

+1

Milian, if you're not around or busy, I can go with the release myself.

Aleix

On Fri, Jun 22, 2012 at 10:31 PM, Andreas Pakulat <apaku at gmx.de> wrote:

> Hi,
>
> On Fri, Jun 22, 2012 at 9:48 PM, Nicolás Alvarez <
> nicolas.alvarez at gmail.com> wrote:
>
>> 2012/6/22 Nicolás Alvarez <nicolas.alvarez at gmail.com>:
>> > 2012/6/10 Milian Wolff <mail at milianw.de>:
>> >> On Sunday 10 June 2012 17:39:25 Andreas Pakulat wrote:
>> >>> Hi,
>> >>>
>> >>> On Sun, Jun 10, 2012 at 10:17 AM, Andreas Pakulat <apaku at gmx.de>
>> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > On Sun, Jun 10, 2012 at 1:20 AM, Friedrich W. H. Kossebau <
>> >>> >
>> >>> > kossebau at kde.org> wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> after lot of month I tried to build the current 4.3 branch (on
>> commit
>> >>> >> 5c288e2014c043593f8c6385b2aefb221615a652) and I am hitting a build
>> >>> >> problem in
>> >>> >> kdevelop/languages/cpp/cpplanguagesupport.cpp (see attached log
>> for full
>> >>> >> output). Any idea what is wrong for me?
>> >>> >>
>> >>> >> Yes, deleted any 4.3 branch I had locally. But refetching did not
>> improve
>> >>> >> things.
>> >>> >>
>> >>> >> The looking at the stuff on the central repo like
>> >>> >>
>> >>> >>
>> https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/
>> >>> >> revisions/4.3/entry/CMakeLists.txt I wonder about the
>> KDEVELOP_VERSION,
>> >>> >> does not look correct. The needed KDevPlatform version 1.3.60 also
>> looks
>> >>> >> strange.
>> >>> >
>> >>> > Can't look at this right now due to the identity.kde.org downtime,
>> my
>> >>> > local checkout from May 12th, however still shows a separate 4.3
>> head. So
>> >>> > if there is a problem it was introduced only recently.
>> >>>
>> >>> Hmm, seems like someone did a reset at some point, I can see this in
>> the
>> >>> history:
>> >>>
>> >>> The last commit into the original 4.3 branch following the v4.3.1 tag
>> >>> (which was still ok) is:
>> >>> 6b95b832d72696df0278ac7b9d290c96b798ef07
>> >>>
>> >>> That follows a merge of 4.3, probably into master. And then next
>> there are
>> >>> a few scripty commits (1e692b9d495d9bfd3af54f2769d4c764e7e197d7 and
>> >>> following) and then milian
>> >>> comitted based on that last scripty commit again
>> >>> (86f4848f9f6324540c0ca9c70dfd81ff0e6b1cfc) . There's been a few more
>> >>> commits and ultimately this branch leads to the current 4.3 tip
>> >>> (5c288e2014c043593f8c6385b2aefb221615a652).
>> >>>
>> >>> So I guess 4.3 needs to be reset
>> >>> to 6b95b832d72696df0278ac7b9d290c96b798ef07 and then each of the
>> following
>> >>> commits on the wrong 4.3 branch need to be cherry-picked, except for
>> the
>> >>> scripty-ones (those will just be done again by scripty on its next
>> run).
>> >>>
>> >>> I'm cc'ing milian explicitly to make him aware of this.
>> >>
>> >> Hey, thanks for the notification.
>> >>
>> >> Can anyone look into this? PovAddict?
>> >
>> > This seems to be partly my fault. I'm still investigating what exactly
>> > went wrong.
>> >
>> > Fixing it looks tricky, because many commits were done on top of the
>> > bad merge, and the 4.3 branch was merged into other branches. If I fix
>> > only 4.3, many commits will be duplicated (once in the fixed 4.3
>> > branch, and again in the non-fixed 4.3 as merged in the other
>> > branches)...
>>
>> After looking at the server logs, here's the whole story:
>>
>> - The 4.3 branch was at fd5ea0 (which is coincidentally the commit
>> tagged as v4.3.1).
>>
>> - Milian accidentally pushed 5799ab ("Fix gcc include-path…") into
>> both master and 4.3, despite being created over master history. The
>> server allowed this with no errors, because 4.3 had been merged into
>> master recently, so this was a proper descendant of the previous 4.3
>> branch state (otherwise it would have needed a force-push). This is
>> similar to when Aleix accidentally merged master into 4.3 rather than
>> the other way around.
>>
>> - I force-pushed to undo this push and reset 4.3 back to fd5ea0. Repo
>> is now fixed.
>>
>> - Milian pushed 6b95b8 into 4.3. This was a proper cherry-pick of
>> 5799ab over 4.3 history. Repo is still OK.
>>
>> - However, Scripty had already fetched the repository between Milian
>> mis-pushing and me fixing it. So on its next run, with its local
>> branch pointing at 5799ab, it pulled from 4.3, merging 6b95b8 onto
>> 5799ab, doing its translation-update commit on top, and pushing to
>> 4.3. This essentially re-introduced the bad commit (5799ab), and the
>> master history attached to it, into 4.3.
>
> Don't worry if you can't follow this part, the important thing is that
>> scripty re-pushed the bad commit I had removed.
>>
>> - Scripty did a few more translation commits on top of the current
>> mess, reaching 60f2e5.
>>
>> - I was notified of the problem with scripty, and reset the 4.3 branch
>> to 725213. *This is what went wrong*. I should have reset the branch
>> to fd5ea0 again instead. 725213 was a merge from 4.3 to master, pushed
>> into master, supposed to be only in master. I don't know if I
>> misunderstood the problem, the history graph, or if I simply
>> copy-pasted the wrong thing.
>>
>> Since then, there have been 25 commits (11 of them from scripty)
>> pushed into 4.3, on top of 725213. In addition, 4.3 was merged into
>> master a few times, and master was also merged into the 'unittest' and
>> 'file-templates' feature branches.
>>
>> I can fix this by rebasing the 25 commits done after 725213 on top of
>> fd5ea0 instead. The problem is that due to the above-mentioned merges,
>> the commits in 725213..4.3 are also present in master, unittest, and
>> file-templates. I would have to rewrite all four branches... Fixing
>> 4.3 alone would mean the full history would have duplicated commits,
>> and as soon as 4.3 is merged into master (which is supposed to happen
>> regularly), the log of master alone would show those duplicated
>> commits.
>>
>> However, rebasing four public branches including master is obviously
>> problematic... Anyone who cloned or pulled since April(!) would be
>> "affected". Plus https://github.com/Gnurou/kdevelop which would need
>> rebasing on top of the new master too.
>>
>> Suggestions, questions, sighs, finger-pointing welcome.
>>
>
> Hmm, I'd say reset 4.3 to the v4.3.1 tag and close it for further commits.
> Release 4.4.0  asap from master. Anything else will be a royal pita for
> every users thats not just pulling branches from the repository.
>
> As far as I understood the history would then look as if someone started a
> local branch on v4.3.1 and did some commits and finally merged his branch
> into master instead of back to 4.3 and others started from that point in
> master. Just that 'someone' were actually multiple people and scripty and
> the branch wasn't quite so local :|
>
> Andreas
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120622/5119029a/attachment.html>