annotate contrib/wix/contrib.wxs @ 37337:d257c5f2a940

tests: add test extension implementing custom filelog storage

In order to better support partial clones, we'll need alternate
repository storage mechanisms that aren't based on revlogs.

Today, the interface for repository storage isn't very well defined.
And there are various layering violations and assumptions made
throughout the code that storage is backed by revlogs.

In order to support alternate storage mechanisms, we'll need to
formally declare and adhere to interfaces for storage. This will
be a long, arduous process.

This commit creates an extension that implements non-revlog storage
for files. It defines a custom type that quacks like the existing
revlog/filelog API but isn't backed by a revlog. The backing storage
is - for simplicity reasons - a CBOR index and per-node files
representing fulltext data.

The localrepository class is modified so file(f) returns instances of
this class instead of filelog instances.

The purpose of this extension is to tease out what the actual filelog
interface is - based on running the test harness - so we can formalize
that interface and then implement a *real* alternate storage backend.

Using `run-tests.py --extra-config-opt` to run the test harness
with this extension enabled yields 83 failures out of 634 ran
tests.

The most common test failures are due to:

* Issues with `hg verify`
* LFS and largefiles (probably flags processing related)
* Narrow.
* Any test touching or inspecting individual filelog paths.
* help and error output that is confused by the presence of an
  extension.
* `hg debug*` commands doing low-level, revlog-y things.

An 88% pass rate is pretty good for an initial implementation if you
ask me!

There is a bit of duplicate code in the new extension. That's by
design: a point of this code is to tease out dependencies on revlog.
That being said, there is opportunity to consolidate code by moving
things out of the revlog API. For example, DAG traversal operations
don't necessarily need to be implemented at the storage level. (Although
for performance reasons they probably do.) Once we have a more
well-defined interface, we could probably define the default
implementations in terms of the base interface, pull those in via
class inheritance, and have implementations override with faster
versions if they so choose. (Or something like that.) But for now,
the duplicate code should be acceptable.

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

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">

  <?include guids.wxi ?>
  <?include defines.wxi ?>

  <Fragment>
    <ComponentGroup Id="contribFolder">
      <ComponentRef Id="contrib" />
      <ComponentRef Id="contrib.vim" />
    </ComponentGroup>
  </Fragment>

  <Fragment>
    <DirectoryRef Id="INSTALLDIR">
      <Directory Id="contribdir" Name="contrib" FileSource="$(var.SourceDir)">
        <Component Id="contrib" Guid="$(var.contrib.guid)" Win64='$(var.IsX64)'>
          <File Name="bash_completion" KeyPath="yes" />
          <File Name="hgk" />
          <File Name="hgweb.fcgi" />
          <File Name="hgweb.wsgi" />
          <File Name="logo-droplets.svg" />
          <File Name="mercurial.el" />
          <File Name="tcsh_completion" />
          <File Name="tcsh_completion_build.sh" />
          <File Name="xml.rnc" />
          <File Name="zsh_completion" />
        </Component>
        <Directory Id="vimdir" Name="vim">
          <Component Id="contrib.vim" Guid="$(var.contrib.vim.guid)" Win64='$(var.IsX64)'>
            <File Name="hg-menu.vim" KeyPath="yes" />
            <File Name="HGAnnotate.vim" />
            <File Name="hgcommand.vim" />
            <File Name="patchreview.txt" />
            <File Name="patchreview.vim" />
            <File Name="hgtest.vim" />
          </Component>
        </Directory>
      </Directory>
    </DirectoryRef>
  </Fragment>

</Wix>