Conflicts exist if move to jdk14

[Martin Buchholz]

I don't know of any good answers for this fundamental engineering problem
For private use, I like to maintain a stack of patches and rebase them all
the time, and e.g. fig supports that.
But you can't do that with shared branches/repos - you'll break all your
users.
The problem with merges is that any actual work done to resolve conflicts
is not managed, and is a needle in the haystack of changes being merged.

On Tue, Mar 31, 2020 at 11:40 AM Man Cao <manc at google.com> wrote:

> I also looked at how other projects (portola and shenandoah) handle this.
> Unlike tsan and loom, which maintain separate development branches,
> both portola and shenandoah just maintain a single "default" branch. They
> also have separate repositories for JDK11, JDK12, etc.
> They also do regular "Merge" commits to sync with jdk/jdk in the master
> development repository.
> So I think we should go with "hg merge". Mercurial should be able to
> differentiate commits between the tsan and jdk/jdk. The "tsan" branch in
> our repository would help separate out the changes further.
>
> I guess the main problem with "hg rebase" is that it generates a whole new
> set of changeset IDs (hashes). We don't want to change the IDs for
> changesets that have already been pushed.
>
> Any more concerns before I try a merge with jdk14-ga?
>
> -Man
>