KDevelop 4.3 branch screwed again?

Fri Jun 22 20:31:08 UTC 2012

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120622/ec731858/attachment.html>