Repository? -- How many lines of development?

[Stuart Marks]

On 11/28/16 5:07 PM, Joseph D. Darcy wrote:
> On 11/28/2016 3:51 PM, John Coomes wrote:
>> 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?

For the "latest promoted build" case the John is concerned about, I think it 
should be sufficient to have a tag that's updated to point to the latest 
promoted build. Unlike the jdk-10+123 style tags, which are permanent, the 
"latest-promoted-build" tag would be updated continually. This would be a simple 
addition to the tagging process.

Martin said:

> People do "continuous testing and integration" these days.  Set up your
> integration pipeline so that it is always running.  The pipeline
> automatically promotes changesets to master when all tests pass.  Easy!
> Then every master changeset is equally stable to a "promoted build".

There's some additional ceremony around a "promoted build" that occurs over and 
above the output of ordinary CI builds. In particular, such builds are published 
to java.net, and they're archived for the long term, whereas the CI builds are 
thrown away after a while.

But it would be nice to have a record of the latest green CI build, in case 
there happens to be instability or regressions at the tip. As Joe said, having 
an entire separate forest for this seems wasteful, when essentially all we need 
is a tag.

The problem with using a tag is that updating a tag in Mercurial requires a 
changeset. If we get (say) ten green builds per day from the CI system, that's 
ten tag-update changesets. I'd think that would add an excessive amount of 
clutter to the history.

Even if we rate-limited the "latest-good-build" tagging to once a day, that's 
still quite a bit of clutter, and it would lag the actual latest good build by 
up to 24 hours.

Another possibility would be to use bookmarks. A bookmark is a name that points 
to a changeset, like a tag. But unlike tags, bookmarks aren't versioned, and so 
updating them doesn't require a changeset. In addition, bookmarks have a feature 
that they automatically are advanced when a new changeset is committed as a 
child of a bookmarked changeset. This works for cases like branchy development, 
but it's actually counterproductive for what we're trying to do here. (The 
auto-advance feature would probably be useful in the sandbox, though.)

Suppose for example there is a bookmark named "latest-good-build" that happens 
to be at the tip at the moment. I, as an individual developer, might do a pull, 
commit a fix, and push it. This automatically moves the "latest-good-build" to 
this new changeset, and this bookmark change is published to everyone along with 
the changeset. But if my changeset has a bug that my testing didn't uncover, 
then "latest-good-build" is now a lie!

Only the CI system should be able to update the latest-good-build bookmark. 
Individuals can disable auto-advance manually when refreshing, like so:

     hg pull
     hg update latest-good-build
     hg bookmarks --inactive latest-good-build

This seems rather easy to get wrong, though. Perhaps there's another way of 
dealing with bookmarks that I haven't thought of.

s'marks