[Updated] D9677: upgrade: use copy+delete instead of rename while creating backup

marmoute (Pierre-Yves David) phabricator at mercurial-scm.org
Wed Jan 13 10:34:16 UTC 2021


This revision now requires changes to proceed.
marmoute added a comment.
marmoute requested changes to this revision.


  In D9677#147085 <https://phab.mercurial-scm.org/D9677#147085>, @mharbison72 wrote:
  
  > In D9677#146367 <https://phab.mercurial-scm.org/D9677#146367>, @pulkit wrote:
  >
  >> In D9677#146243 <https://phab.mercurial-scm.org/D9677#146243>, @marmoute wrote:
  >>
  >>> As pointed in a pa previous comment, this is problematic, because this does not preserve the same consistency as the previous code
  >>
  >> While the copy consistency can be maintained here, future changes (WIP) will break the consistency more. In upcoming work, we want to only touch parts of repository which needs to be updated. This will lead us to do selectively moving data from the upgraded repository to the current one.
  >
  > @marmoute are you OK with this explanation?
  
  Not at all :-)
  
  Currently we have:
  
  1. a fully consistent repository in place (while the upgrade run)
  2. a missing store during a split second (old store was rename)
  3. a fully consistent repository in place (the upgraded store was rename in place)
  
  The process ensure a very narrow inconsistency window and a very clear invalid state "the store is either valid or missing."
  
  The change in this part move the (2) step to a much longer operation where elements get copied one by one. As a result we get a much longer window of inconsistency with a much wonkier inconsistency state as we get "mixed" files within the resulting store.
  
  So overall this change is going in the wrong direction.
  
  We are currently looking for lighter upgrade for 2 feature "persistent nodemap" and "share-safe". And I don't think either of them need this kind of change. A upgrade processs for persistent nodemap could be:
  
  1. write new persistent nodemaps (data file, then docket) that nobody will read without the requirements.
  2. add the new requirement
  
  The downgrade being the reverse (remove the requirement, remove the nodemaps)
  
  And something similar could be done for the share-safe upgrade
  
  1. write a new `.hg/store/requirements` that nobody will read yet
  2. rewrite `.hg/requirements`

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D9677/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D9677

To: pulkit, #hg-reviewers, marmoute
Cc: mharbison72, ulrickaka, marmoute, mercurial-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-patches/attachments/20210113/7ab72c80/attachment-0002.html>


More information about the Mercurial-patches mailing list