[Updated] D9195: copies: split creation of the graph and actual checking again

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  In D9195#138266 <https://phab.mercurial-scm.org/D9195#138266>, @pulkit wrote:
  
  >> (spoiler: we will find some bug)
  >
  > Unable to find the bug in upcoming patches.
  
  The bug is fixed in D9199 <https://phab.mercurial-scm.org/D9199>. Before that patch, the upgrade process was computing copy related sidedata, but failed to set some revlog related flag to mark that changeset was relevant to copy tracing. As a result using an upgraded repository for copytracing returned bad result. When the original test was written, the upgrade worked fine, however, when we later introduced this new flag (for performance reason) the feature silently broke without the test noticing that.
  
  To me this silent breakage highlight the need for more thoughtful testing of the upgrade. We need more that just checking that the upgrade ran without crashing and that some metadata are there. We need to actually check that an upgraded repository can do copy tracing as fine as a repository that was using the feature from the start. That way, we can detect future breackage coming from code/data area we did not expected.
  
  > In D9195#138236 <https://phab.mercurial-scm.org/D9195#138236>, @marmoute wrote:
  >
  >> In D9195#138226 <https://phab.mercurial-scm.org/D9195#138226>, @martinvonz wrote:
  >>
  >>> I really don't like this patch. I did the split back in D8377 <https://phab.mercurial-scm.org/D8377> because I found this format very hard to read. IIRC, at least @pulkit agreed with me. I don't understand why testing of upgrades require this structure.
  >>
  >> Because to test the upgrade process, we need all the test-case changeset to be created before we run the upgrade itself.
  >
  > Hm, we can run upgrade in the end then from what I understand.
  
  My ultimate goal here is to have the tests in this file to run on a upgraded repository. To do so I need the following this to happens in a specific order :
  
  1. create changeset without copy tracing sidedata
  2. run the repository upgrade to add copy tracing sidedata
  3. check that the copy tracing is yielding that result we want
  
  The upgrade process can only run once. So I need all the changesets created because I run it. Once the upgrade is done, I can check the copy tracing behavior.
  
  Is this clearer to you?

REPOSITORY
  rHG Mercurial

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

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

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