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

[Albert Astals Cid]

El Dilluns, 21 de juliol de 2014, a les 15:53:56, Ralf Habacker va escriure:
> 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/revision
> >> s/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/revision
> >> s/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-rep
> > os.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 ?

As said my suggestion is do fixed in 4.14 and merge to master, do features and 
non-bugfix changes in master.

But you're free to work as you want :)

Cheers,
  Albert

> 
> Regards
> Ralf