JDK8 Preliminary Repository Layout

[Kelly O'Hair]

On Apr 28, 2011, at 2:48 AM, Fredrik Öhrström wrote:

> 2011/3/11 Kelly O'Hair <kelly.ohair at oracle.com>
> in the repository. If there are frequent pushes going on, either from too much activity or too many developers,
> someone may experience a:
>   hg push    # fails because you need to do a pull "too many heads message"
>   hg pull -u && hg merge && hg commit -m Merge    #  Or hg fetch
>   hg push   # fails because you took too long and someone else pushed a new one
>   hg pull -u && hg merge && hg commit -m Merge    #  Or hg fetch
>   hg push   # fails because you took too long and someone else pushed a new one
> 
> I suppose this is related to the fact that mercurial has developed over time.
> But today, using merge to solve this problem would be ill advised.
> I think it is much better to use the rebase extension to do 
> hg pull --rebase
> 
> This will move your outgoing changes to the tip and avoid the creation of an unnecessary merge node.

This rebase extension (which is an extension that needs to be enabled) has not always existed, it's a nice addition
and will be very useful. But .... it does come with come cautions, effectively a rebase will regenerate
changesets, and anything that regenerates changesets needs to be used with great care, just like rollbacks.
And hidden in the rebase, is a merge, potentially many merges, potentially merges where file
changes actually need to be resolved. With rebase, the merges just get folded into a new changeset.

There are dumb merge changesets, where no files were in conflict, which the rebase can easily fix,
but when there are file conflicts, you may run a risk here of mis-merging if you are not careful.
And once rebased, your new changeset might not be the same changeset that you originally created,
so great care is always advised with a 'hg pull', regardless of how you manage the merge.
Depending on how much you pulled over, re-builds and re-tests may be important.

> 
> Assuming that you have a large number of committers at work at the same time, a simple solution
> is to have the committers add themselves to a queue, then they get a message (IM,mail or otherwise)
> when they have exclusive access. When they are done, they relinquish their exclusive acces or
> it will be revoked automatically after 5 minutes.

In my opinion, a collision between 2 developers in a small window of time (say 3mins) should be
rare, and it's easily resolved. If it happens frequently, I would tend to question what is going on.
That many changesets being pushed in at the same time may be a sign of something seriously wrong
with development, the number of changesets per day should not be in the 1,000's.

Yes, I see John mentioned the stuffed animal Teamware tokens, representing locks on workspaces, I remember those. ;^)
With the old Teamware workspaces, the equivalent pull/merge was often very very slow, 30mins
sometimes 60mins. But with Mercurial, the time to push is measured in minutes, sometimes seconds.
I just don't see a need for locks. More important in my mind, is making sure we get good changeset pushes.

-kto

> 
> Fredrik Öhrström

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20110503/1a084459/attachment.htm>