Trimming dead branches

[Becker, Mischa J]

> -----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?  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)

> If we "backout" such dead branches, does that modify our repo in any
> way other than removing those dead branches?

Backout adds a new commit backing out the earlier commit, it doesn't remove dead branches.  There are three main options for removing those 'failed' commits.

1. Use evolve to mark the dead branches as obsolete.  The commits aren't physically removed from the repo but are hidden and invisible by default.

2. Clone the existing repo to a new repo taking care to exclude the dead branches from the clone. When done, replace the existing repo with the clone.

3. Enable MQ and strip the 'failed' commits from the repo.  Do this on a copy of the repo to make sure you don't accidently break anything.  Once the copy is fixed, replace the original repo. (In TortoiseHg, once MQ is enabled, you can right-click the bad commit and select Modify History -> Strip...)

Options 2 & 3 require anyone who has a clone of the main repo to either do the same process themselves to strip out the unwanted commits or to re-pull a new clone after the main repo is fixed.

> For the record, it appears that those file locking issues are caused by
> a combination of:
> * the 3 of us using the same repo on a remote Windows share,
> * which is also used by the (web-based) product we develop in;
> WebFOCUS, which appears to keep locks on certain files (namely
> procedures) longer than necessary,
> * in combination with us using the keywords extension, because our
> users like to be able to see whether the production version of their
> reports is up-to-date with the latest developments that they cleared
> for production use.
>
> That's a bit of a tricky setup we realise, but we haven't found a way
> around that actually works. Separate development environments didn't
> work out, for example.

I don't recall if you have ever talked about this on the email list.  If you are willing to try changing your setup, let us know what problems you were having.  Maybe someone will know a fix.

Mischa Becker

________________________________

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.