KDevelop 4.3 branch screwed again?

[Milian Wolff]

On Friday 22 June 2012 22:52:08 Aleix Pol wrote:
> +1
> 
> Milian, if you're not around or busy, I can go with the release myself.

Sure, feel free to do that.

As I said, I'll be back with more time and energy in ~2-3 weeks!

Cheers

> 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
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120625/ffb1b898/attachment.sig>