Proposal on how we should handle syncing between stabilisation forests and always open 7u (original) (raw)

Chris Hegarty chris.hegarty at oracle.com
Fri Nov 4 03:29:39 PDT 2011

On 04/11/2011 09:58, Alan Bateman wrote:

On 03/11/2011 16:02, Edvard Wendelin wrote: .....

If you have any feedback, please let me know before Monday. Edvard - what does this mean for the history? Just thinking of someone with a clone of jdk7u/jdk7u, they will no longer be able to do a "hg update" to update the working copy to get to any build of any update, they will only be able to get to builds that were done prior to forking for stabalization. Also just wondering if it will be confusing to have different changeset ids for the same fix.

Good questions Alan (which I don't have the answers to!)

I just wanted to point out that the jdk7u-dev forest of repos allows duplicate bugIds's, and some developers have already been pushing the same changes into both the stabilization forest and the jdk7u-dev forest using different changeset ids. I don't like this approach because of what it does to the history/merges/etc.

I'd be more in favor of an auto sync (or something) between the stabilization forest and jdk7u-dev. Or where possible import the exact changeset id into jdk7u-dev directly after the push into the stabilization repo.

-Chris.

-Alan.

More information about the jdk7u-dev mailing list