view tests/test-narrow-sparse.t @ 42054:399ed3e86a49

py2exe: add workaround to allow bundling of hgext3rd.* extensions

py2exe doesn't know how to handle namespace packages *at all*, so it treats
them like normal packages. As a result, if we try and bundle hgext3rd.evolve
in a py2exe build, it won't work if we install evolve into the virtualenv. In
order to work around this, tortoisehg installs hgext3rd.evolve etc into its
staged hg directory, since it doesn't use a virtualenv. As a workaround for us,
we'll just allow any extra packages users want bundled are part of hg during
the pseudo-install phase that py2exe uses. I'm not happy about this, but it
*works*.

As a sample of how you'd make an MSI with evolve bundled:

    import os
    import shutil
    import subprocess
    import tempfile

    def stage_evolve(version):
      """Stage evolve for inclusion in py2exe binary."""
      with tempfile.TemporaryDirectory() as temp:
        evolve = os.path.join(temp, "evolve")
        subprocess.check_call([
            "hg.exe",
            "clone",
            "https://www.mercurial-scm.org/repo/evolve/",
            "--update",
            version,
            evolve,
        ])
        dest = os.path.join('..', 'hgext3rd', 'evolve')
        if os.path.exists(dest):
            shutil.rmtree(dest)
        shutil.copytree(os.path.join(evolve, "hgext3rd", "evolve"), dest)


    def main():
      stage_evolve('tip')
      print("\0")
      print("hgext3rd")
      print("hgext3rd.evolve")
      print("hgext3rd.evolve.hack")
      print("hgext3rd.evolve.thirdparty")


    if __name__ == "__main__":
      main()

is a script you can pass to the wix/build.py as --extra-packages-script,
and the resulting .msi will have an hg binary with evolve baked in. users
will still need to enable evolve in their hgrc, so you'd probably also
want to bundle configs in your msi for an enterprise environment, but that's
already easy to do with the support for extra features and wxs files in the
wix build process.

Differential Revision: https://phab.mercurial-scm.org/D6189

Testing interaction of sparse and narrow when both are enabled on the client
side and we do a non-ellipsis clone

#testcases tree flat
  $ . "$TESTDIR/narrow-library.sh"
  $ cat << EOF >> $HGRCPATH
  > [extensions]
  > sparse =
  > EOF

#if tree
  $ cat << EOF >> $HGRCPATH
  > [experimental]
  > treemanifest = 1
  > EOF
#endif

  $ hg init master
  $ cd master

  $ mkdir inside
  $ echo 'inside' > inside/f
  $ hg add inside/f
  $ hg commit -m 'add inside'

  $ mkdir widest
  $ echo 'widest' > widest/f
  $ hg add widest/f
  $ hg commit -m 'add widest'

  $ mkdir outside
  $ echo 'outside' > outside/f
  $ hg add outside/f
  $ hg commit -m 'add outside'

  $ cd ..

narrow clone the inside file

  $ hg clone --narrow ssh://user@dummy/master narrow --include inside/f
  requesting all changes
  adding changesets
  adding manifests
  adding file changes
  added 3 changesets with 1 changes to 1 files
  new changesets *:* (glob)
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd narrow
  $ hg tracked
  I path:inside/f
  $ hg files
  inside/f

XXX: we should have a flag in `hg debugsparse` to list the sparse profile
  $ test -f .hg/sparse
  [1]

  $ cat .hg/requires
  dotencode
  fncache
  generaldelta
  narrowhg-experimental
  revlogv1
  sparserevlog
  store
  treemanifest (tree !)

  $ hg debugrebuilddirstate