[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