copies: add test that makes both the merging csets dirty and fails This patch is a part of series which is about the case when both the merging csets are not descendant of merge base. The existing code assumes if c1 is dirty there shouldn't be any partial copies from c2 i.e both2['incomplete'] and same for c2, if c2 is dirty both1['incomplete'] should be empty, but this is not the right assumption. Now as we know we can have both c1 and c2 dirty at the same time, it is possible that c1 is dirty and both2['incomplete'] has some value. Or if c2 is dirty and both1['incomplete'] has some value. Added test shows that because of this assumption it could fail. Differential Revision: https://phab.mercurial-scm.org/D5962

copies: add test that makes both the merging csets dirty and run w/o error This series of patches is to cover a case in fullcopytracing algorithms where both the merging csets are not descendant of merge base. In this algorithm we call a merging cset "dirty" if that cset is not the descendant of merge base. That said, added test in this patch cover case when both the merging csets are "dirty". Actually this case of "both dirty" was encountered by Pulkit when he was working on content-divergence where it is possible that both the csets are not descendant of merging base. For reference you can look into: https://phab.mercurial-scm.org/D3896 As this test run fine without any error and correctly traced the copies, I added this test to make sure that it doesn't break even after I will modify some code in next patches to fix an error. Next patch adds the tests where this algorithm throws an error for the same case of "both dirty". Differential Revision: https://phab.mercurial-scm.org/D5961

tests: stabilize test-bundle.t on Windows Similar to 92055d539e49.

discovery-helper: use reflink copy if available A reflink copy will copy the files "as usual" but keep using the same data block underneath. This is only supported by "copy on write" file system like btrfs or zfs. This will achieve similar performance that the existing hardlink clone that Mercurial performs with the same initial space saving. However, it will behave better on revlogs start being touch by strip. Instead of duplicating all data in the touched revlogs, only the block actually affected by the strip will be duplicated. This save a lot of space when building many variants of large repositories. The --reflink=always flag make sure the `cp` call fails if reflink copies are not supported. Falling back to local clone.

discovery-helper: bail out if destination already exists

discovery-helper: move repository creation in a function This makes it easier to update this duplicated code. (we do a small output fix as we go)

discovery-helper: add an extra argument to generate only one repo This is useful to generate left and right in parallel when dealing with very large repositories.

wix: remove enum and future packages These were cargo culted from the THG installer code. I'm not sure what needs them in THG land. But the official MSIs certainly do not - at least not as direct dependencies. .. bc:: The Windows MSI installers no longer include the enum and future Python packages. Differential Revision: https://phab.mercurial-scm.org/D6101

wix: remove pywin32 This dependency was for ancient Mercurial versions. We recently removed it from the Inno Setup installers. So let's remove it from the WiX installers as well. .. bc:: The Windows MSI installers no longer include the pywin32 Python package. Differential Revision: https://phab.mercurial-scm.org/D6100

wix: remove sphinx and dependencies Sphinx was cargo culted into our install environment as part of emulating TortoiseHG's behavior. THG seems to install Sphinx in order to generate THG specific documentation. We don't appear to need Sphinx or any of its dependencies in the official WiX installers. So remove it. This shaves ~1MB off the size of the MSI installers. .. bc:: The Windows MSI installers no longer include the Python sphinx package and its various dependencies. Differential Revision: https://phab.mercurial-scm.org/D6099