Betr: RE: Trimming dead branches

[Becker, Mischa J]

> -----Original Message-----
> From: Alban Hertroys [mailto:alban.hertroys at apollovredestein.com]
> Sent: Thursday, February 12, 2015 1:37 AM
>
> "Becker, Mischa J" <mischa.becker at kroger.com> wrote on 11/02/2015
> 22:41:44:
>
> > > -----Original Message-----
> > > From: Mercurial [mailto:mercurial-bounces at selenic.com] On Behalf Of
> > > Alban Hertroys
> > > Sent: Wednesday, February 11, 2015 1:25 AM
> > > To: mercurial at selenic.com
> > > Subject: Trimming dead branches
> > >
> > > We're currently having some issues with failing commits due to file
> > > locking issues and those failed commits are causing dead branches in
> > > our repo. In TortoiseHg's workbench we can see several new branches
> > > with commit messages equal to the final successful commit attempt.
> >
> > Your commits obviously committed, otherwise you wouldn't see them in
> > the workbench.  This sounds like a problem with a commit hook or
> other
> > process.  Is there anything actually wrong with those 'failing'
> > commits or are their contents exactly the same as the 'successful'
> > commit?
>
> Tortoise's Visual diff reports that there are no changes between the
> successful commit and the failed commit (branch).
>
> That actually surprises me, as so far I was under the assumption that
> the issue involved our usage of the $Revision$ tags. An assumption that
> would have explained the need for a file lock on commit. Now I'm
> wondering what's causing the locking conflict from the Mercurial side
> of the problem...
>
> I also just noticed another detail in Hg Workbench: the commit looks
> like a branch (the line at the left side shows a split), but both
> branches are named 'default'. hg heads shows a list that any hydra
> would be jealous of, that list includes the failed commits.

My guess is that after the failure the repo is still pointing to the original parent.  It doesn't know the current dirstate really is a new commit.  This is either the cause of the failure or how it tries to recover from the failure.

e.g. A commit on rev 1 creates rev 2.  The repository sees the dirstate of rev 2 but thinks the current parent is still rev 1.  All the files that were committed in rev 2 still show as being modified because it is still comparing to rev 1.  Redoing the commit creates rev 3.  Repeat until successful.  If it fails 3 times before succeeding, you now have 4 anonymous heads on the branch you were trying to commit to, the last of which is now the current parent.

> > If those commits are wrong, I suggest seeing if you can't prevent
> > the commit from happening in the first place via the commit hook or
> > rolling it back immediately after the failure. (see hg help rollback)
>
> hg rollback looks like it would hurt us (and is documented to be
> dangerous and deprecated), because "It will also restore the dirstate
> at the time of the last transaction, losing any dirstate changes since
> that time.".

Doing a roll-back immediately after a commit basically does an uncommit and the dirstate is returned to what it was just prior to the commit with everything still waiting to be committed. I've never actually lost any pending changes but if I'm worried about it I shelve everything that hasn't been committed yet.  You are right though, it's risky to do this type of thing in a repo that multiple people touch.

Mischa

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.