Mercurial > hg
view tests/test-push-checkheads-unpushed-D2.t @ 44767:234882d17814 stable
packaging: support building WiX installers with PyOxidizer
We initially implemented PyOxidizer support for Inno installers.
That did most of the heavy work of integrating PyOxidizer into
the packaging system. Implementing WiX installer support was
pretty straightforward.
Aspects of this patch look very similar to Inno's.
The main difference is the handling of the Visual C++
Redistributable Runtime files.
The WiX installer was formerly using merge modules to
install the VC++ 9.0 runtime because this feature is
supported by the WiX installer (it isn't easily available
to Inno installers).
Our strategy for the runtime files is to install the
vcruntime140.dll file next to hg.exe just like any other
file. While we could leverage WiX's functionality for invoking
a VCRedist installer, I don't want to deal with the complexity
at this juncture. So, we let run_pyoxidizer() copy vcruntime140.dll
into the staging directory (like it does for Inno) and our
dynamic WiX XML generator picks it up as a regular file and
installs it.
We did, however, have to teach mercurial.wxs how to conditionally
use the merge modules. But this was rather straightforward.
Comparing the file layout of the WiX installers before and
after:
* Various lib/*.{pyd, dll} files no longer exist
* python27.dll was replaced by python37.dll
* vcruntime140.dll was added
All these changes are expected due to the transition to
Python 3 and to PyOxidizer, which embeded the .pyd and .dll files
in hg.exe.
Differential Revision: https://phab.mercurial-scm.org/D8477
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Mon, 20 Apr 2020 17:42:50 -0700 |
parents | 34a46d48d24e |
children | 122f0b59f5f0 |
line wrap: on
line source
==================================== Testing head checking code: Case D-2 ==================================== Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This case is part of a series of tests checking this behavior. Category D: remote head is "obs-affected" locally, but result is not part of the push TestCase 1: remote branch has 2 changes, head is pruned, other is rewritten but result is not pushed .. old-state: .. .. * 1 changeset branch .. .. new-state: .. .. * old head is pruned .. * 1 new branch succeeding to the other changeset in the old branch .. * 1 new unrelated branch .. .. expected-result: .. .. * push allowed .. * pushing only the unrelated branch: denied .. .. graph-summary: .. .. B ⊗ .. | .. A ø⇠○ A' .. |/ .. | ◔ C .. |/ .. ● $ . $TESTDIR/testlib/push-checkheads-util.sh Test setup ---------- $ mkdir D2 $ cd D2 $ setuprepos creating basic server and client repo updating to branch default 2 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd server $ mkcommit B0 $ cd ../client $ hg pull pulling from $TESTTMP/D2/server searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files new changesets d73caddc5533 (1 drafts) (run 'hg update' to get a working copy) $ hg up 0 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ mkcommit A1 created new head $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"` 1 new obsolescence markers obsoleted 1 changesets 1 new orphan changesets $ hg debugobsolete --record-parents `getid "desc(B0)"` 1 new obsolescence markers obsoleted 1 changesets $ hg up 0 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ mkcommit C0 created new head $ hg log -G --hidden @ 0f88766e02d6 (draft): C0 | | o f6082bc4ffef (draft): A1 |/ | x d73caddc5533 (draft): B0 | | | x 8aaa48160adc (draft): A0 |/ o 1e4be0697311 (public): root Actual testing -------------- $ hg push --rev 'desc(C0)' pushing to $TESTTMP/D2/server searching for changes abort: push creates new remote head 0f88766e02d6! (merge or see 'hg help push' for details about pushing new heads) [255] $ cd ../..