Repository? -- How many lines of development?
Joseph D. Darcy
joe.darcy at oracle.com
Tue Nov 29 01:07:50 UTC 2016
On 11/28/2016 3:51 PM, John Coomes wrote:
> On Mon, Nov 28, 2016 at 2:07 PM, Joseph D. Darcy <joe.darcy at oracle.com
> <mailto:joe.darcy at oracle.com>> wrote:
> In a nutshell, the proposal is to replace tracking the known-good
> state in 9 via integrate dev -> master, tag in master, pull down
> to dev process today with just "tag known good in combined
> dev/master" in 10.
> Hi Joe,
> This would make cloning or pulling the "last known good" state more
> difficult. In jdk9, I can always clone/pull from a fixed location
> (http://.../jdk9/jdk9). With the proposal, I would have to first
> clone/pull everything, then examine the tags and sort them (which
> programatically means decoding release and build numbers, ugh), find
> the right tag, then pull/update to get the working dir in the right state.
> Since my clone would have all the changesets, including those beyond
> the "last known good" state, it also makes the use of 'tip' and
> 'default' error prone. If I do some archaeology and run "hg update
> <some_older_rev>", then when I'm done, I can't go back to "last known
> good" with a simple "hg update default". I have to look at the tags
> again, sort them, and so on.
> I think it's more important that cloning or pulling the "last known
> good" state be simple, rather than promoting a build.
> Mercurial bookmarks might be a compromise solution - you can have a
> bookmark with a fixed name (e.g., "stable", "jdk10-stable",
> "last-promoted", whatever) that is updated each time a build is
> promoted. With validation from jcheck, it could be made reasonably safe.
I don't object to having a convenient way to get the last known good
state of the sources, but I think the way we do this in 9, using a
separate 700 MB+ Hg forest, has too much overhead to store a relative
paucity of information.
In terms of evaluating alternatives, are there other ways you see to
record this information in Mercurial?
More information about the jdk10-dev