[umbrello-devel] Does 4.14 contain all the code it should?

[Ralf Habacker]

Am 20.07.2014 21:17, schrieb Albert Astals Cid:
> El Dissabte, 19 de juliol de 2014, a les 11:36:51, Ralf Habacker va escriure:
>> Am 17.07.2014 01:00, schrieb Albert Astals Cid:
>>> Hi guys, i tried merging 4.13 into 4.14 to make sure that all the code
>>> that
>>> was in 4.13 is in 4.14 but i got a huge conflict (i guess you don't like
>>> merging (you should makes things like this very easy)) so i can't be sure
>>> 4.14 contains everything that was in 4.13 too.
>> Usually I personally develop and fix issues in master branch and
>> backport the related commits to stable branches with 'git cherry-pick
>> -x' like shown in
>> https://projects.kde.org/projects/kde/kdesdk/umbrello/repository/revisions/6
>> 5d3e16809d780f06d7a2a0feb0dd2be9246c0f8
>>
>> 4 days ago I tried the way you mentioned: I fixed an issue in kde 4.13
>> https://projects.kde.org/projects/kde/kdesdk/umbrello/repository/revisions/7
>> f661fed65d5948e4de14981858241f63ea8e8de and tried to merge it into 4.14 and
>> master and got the same bad
>> experience :-(
>>
>> The question is why is merging old umbrello branches so much work ? 
After investigation the answer is: Most conflicts came from a code
refactoring (QLatin1String..), which happened in master, merged into
4.14 as Oliver pointed out and are not be in 4.13.
Looks like that this may happen on every major source code refactoring
not be present in a branch to merge from ?
>> Is
>> there any better way ?
> You're not the first to ask this, i just wrote http://tsdgeos.blogspot.com/2014/07/my-way-to-develop-with-git-in-kde-repos.html
>
> Tell me if it convinces you about the benefits
>
>>> Can anyone confirm that 4.14 indeed contains everything it should?
>> Any official way to verify this ?
> Well, you guys know the code, you should be able to read the code and see if everything is in or not :D
>
>> Today I did run the following
>> git checkout -f KDE/4.14
>> git rebase origin/KDE/4.13
>> # skip all conflicted commits
>> git pull --rebase
>>
>> At the end I got two additional commits: One of them
>> 45d7fb6301b2f6f4b2cc595dbd85e8b6f415d43b I have to revert because it was
>> outdated and lead to compile failures.
> Ok, so what i did to try to make sure all from 4.13 was in 4.14 and then got me doubting was this
>
> # Checkout 4.14
> git checkout KDE/4.14 
> # Make sure i have what is in the repos
> git fetch
> git reset --hard origin/KDE/4.14 
> # Merge the repo 4.13 branch -> Get a lot of conflicts
> git merge origin/KDE/4.13
> # diff against the repo 4.14 branch
> git diff origin/KDE/4.14 > Q
To verify completness I resolved all remaining conflicts, did a fresh
KDE/4.14 checkout in a separate directory and did run

diff -r umbrello-4.14 umbrello-4.14-merged

which gave empty output. I assume this answers your initial question.

According to
https://techbase.kde.org/Schedules/KDE4/4.13_Release_Schedule KDE 4.13
branch is finished now, so no further 4.13 merge conflicts will happens.

The remaining question is how to deal with similar situations in the
future ? Sometime there is the need to refactor source code, for example
fixing outdated variable member camel case modes similar to m_Pvar ->
m_var or renaming  classes and so on, which will generates huge commits.
Given the current situation with master and KDE/4.14 as stable branch,
they need to be applied to KDE/4.14 too to avoid massive merge
conflicts. If sometime in the future major refactoring commits are
applied to master and are branched to the next stable branch (maybe
KDE/4.15 or whatever), the same merge conflict problems will happens
with the KDE/4.14 branch ? 

Regards
Ralf