<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 28, 2011, at 2:48 AM, Fredrik Öhrström wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">2011/3/11 Kelly O'Hair <span dir="ltr"><<a href="mailto:kelly.ohair@oracle.com" target="_blank">kelly.ohair@oracle.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
in the repository. If there are frequent pushes going on, either from too much activity or too many developers,<br>
someone may experience a:<br>
hg push # fails because you need to do a pull "too many heads message"<br>
hg pull -u && hg merge && hg commit -m Merge # Or hg fetch<br>
hg push # fails because you took too long and someone else pushed a new one<br>
hg pull -u && hg merge && hg commit -m Merge # Or hg fetch<br>
hg push # fails because you took too long and someone else pushed a new one<br>
</blockquote><br>I suppose this is related to the fact that mercurial has developed over time.<br>But today, using merge to solve this problem would be ill advised.<br>I think it is much better to use the rebase extension to do <br>
hg pull --rebase<br><br>This will move your outgoing changes to the tip and avoid the creation of an unnecessary merge node.<br></div></blockquote><div><br></div>This rebase extension (which is an extension that needs to be enabled) has not always existed, it's a nice addition</div><div>and will be very useful. But .... it does come with come cautions, effectively a rebase will regenerate</div><div>changesets, and anything that regenerates changesets needs to be used with great care, just like rollbacks.</div><div>And hidden in the rebase, is a merge, potentially many merges, potentially merges where file</div><div>changes actually need to be resolved. With rebase, the merges just get folded into a new changeset.</div><div><br></div><div>There are dumb merge changesets, where no files were in conflict, which the rebase can easily fix,</div><div>but when there are file conflicts, you may run a risk here of mis-merging if you are not careful.</div><div>And once rebased, your new changeset might not be the same changeset that you originally created,</div><div>so great care is always advised with a 'hg pull', regardless of how you manage the merge.</div><div>Depending on how much you pulled over, re-builds and re-tests may be important.</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><br>Assuming that you have a large number of committers at work at the same time, a simple solution<br>
is to have the committers add themselves to a queue, then they get a message (IM,mail or otherwise)<br>when they have exclusive access. When they are done, they relinquish their exclusive acces or<br>it will be revoked automatically after 5 minutes.<br></div></blockquote><div><br></div><div>In my opinion, a collision between 2 developers in a small window of time (say 3mins) should be</div><div>rare, and it's easily resolved. If it happens frequently, I would tend to question what is going on.</div><div>That many changesets being pushed in at the same time may be a sign of something seriously wrong</div><div>with development, the number of changesets per day should not be in the 1,000's.</div><div><br></div>Yes, I see John mentioned the stuffed animal Teamware tokens, representing locks on workspaces, I remember those. ;^)</div><div>With the old Teamware workspaces, the equivalent pull/merge was often very very slow, 30mins</div><div>sometimes 60mins. But with Mercurial, the time to push is measured in minutes, sometimes seconds.</div><div>I just don't see a need for locks. More important in my mind, is making sure we get good changeset pushes.</div><div><br></div><div>-kto</div><div><br><blockquote type="cite"><div class="gmail_quote">
<br>Fredrik Öhrström<br>
</div>
</blockquote></div><br></body></html>