On Apr 28, 2011, at 2:48 AM, Fredrik Öhrström wrote: > 2011/3/11 Kelly O'Hair <kelly.oh...@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
