[dmd-beta] Preparation for 2.65

[David Nadlinger]

On Fri, Jan 17, 2014 at 11:06 PM, Martin Nowak <code at dawg.eu> wrote:
> I don't understand the last argument. What's your workflow for updating
> LDC's druntime and phobos?
> How does merging back release branches help here?

We have druntime and Phobos as Git submodules. What we do is more or
less, in Git pseudo-code:
---
cd runtime/druntime
git fetch dlang
git merge dlang/v2.064-beta1 # Release or beta tag, from the release branch.
cd ../..
git commit -am 'Updated LDC to 2.064'

# Time passes

cd runtime/druntime
git fetch dlang
git merge dlang/v2.065-beta1 # Another tag from the next release branch.
cd ../..
git commit -am 'Updated LDC to 2.065'
---

Now, if the older tag (v2.064-beta1) is not in fact an ancestor of the
newer one (v2.065-beta1), we'll have to resolve all the merge
conflicts ourselves again, months after the actual changes were made,
and even though we probably didn't even touch the code on the LDC
side.

The same goes for the ldc branch on our testsuite repository, which we
also reference as a submodule
(https://github.com/ldc-developers/dmd-testsuite).

And even for merging the frontends itself, I've been using Git to good
success for the last few releases, doing something like this:
---
cd dmd
git checkout v2.064

# Create a dummy commit with all the LDC changes to the frontend.
git checkout -b ldc
cp -a ../ldc/dmd2/* src/
git commit -am 'Merged in LDC changes.'

# Now merge the changes, which is easier due to the added context,
# compared to just using "git diff v2.064..v2.065" and applying it to LDC.
git merge v2.065
git commit -m 'Merged in new frontend.'

# Export the patch and apply it to the LDC repository, where it should
apply cleanly.
git diff HEAD^ src > ../ldc-2.064-2.065.diff
---
Exploiting the additional history information in the DMD repository
makes resolving merge conflicts quite a bit easier (and Git can
resolve more of them by itself), but this approach is also thwarted by
diverging histories due to unmerged cherry-picks.


> I think this "extra bit" of effort will make this process unsuitable.
> If you cherry-pick from master onto a release branch you already have to
> resolve conflicts sometimes.
> Now when you merge the release branch back into master the resulting merge
> conflict is non-trivial.
> Difficult merges are usually best resolved by the people who made the code
> changes.

To get everyone to submit their pull request to the right branch by
default is somewhat unrealistic, also because it is sometimes not in
the submitter's responsibility to decide where a change goes (think
semi-critical bug fix that might go into a point release or not). So,
either we would have to tell people to redo their pull requests
against the appropriate branch, which will lead to a general mess, or
the onus will be on the reviewers to include the changes on the right
branch (i.e. manually merging them to the release branch, the pull
request will auto-close once it is merged back to master). Hm, in the
last case, we'd lose auto-tester integration, so I guess that's not an
option…

David