[PATCH 10 of 10] repair: clean up stale lock file from store backup

Augie Fackler raf at durin42.com
Mon Nov 21 22:09:45 EST 2016


> On Nov 21, 2016, at 9:27 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> 
> 
> 
> On 11/06/2016 05:40 AM, Gregory Szorc wrote:
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc at gmail.com>
>> # Date 1478392394 25200
>> #      Sat Nov 05 17:33:14 2016 -0700
>> # Node ID 0e130e8d2156d9f2523c711ef4fefe4ba33e6818
>> # Parent  3d4dd237b705479f8c7475b821ae719893381fa8
>> repair: clean up stale lock file from store backup
>> 
>> So inline comment for reasons.
>> 
>> diff --git a/mercurial/repair.py b/mercurial/repair.py
>> --- a/mercurial/repair.py
>> +++ b/mercurial/repair.py
>> @@ -716,6 +716,12 @@ def _upgraderepo(ui, srcrepo, dstrepo, r
>>     ui.write(_('store replacement complete; repository was inconsistent for '
>>                '%0.1fs\n') % elapsed)
>> 
>> +    # The lock file from the old store won't be removed because nothing has a
>> +    # reference to its new location. So clean it up manually. Alternatively, we
>> +    # could update srcrepo.svfs and other variables to point to the new
>> +    # location. This is simpler.
>> +    backupvfs.unlink('store/lock')
> 
> I think I get why we need to clean the old lock, however I'm not sure how the rest of the old store directory get handled ? Why do we need a special case for the lock file itself?

He’s built up a new store directory over the course of _upgradrepo, and then does `mv store store.old && mv store.new store` (conceptually) once the upgrade process is done.

> 
> --
> Pierre-Yves David
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161121/9ca05de8/attachment.sig>


More information about the Mercurial-devel mailing list