##// END OF EJS Templates
hg: allow extra arguments to be passed to repo creation (API)...
hg: allow extra arguments to be passed to repo creation (API) Currently, repository creation is influenced by consulting the ui instance and turning config options into requirements. This means that in order to influence repository creation, you need to define and set a config option and that the option must translate to a requirement stored in the .hg/requires file. This commit introduces a new mechanism to influence repository creation. hg.repository() and hg.peer() have been taught to receive a new optional argument defining extra options to apply to repository creation. This value is passed along to the various instance() functions and can be used to influence repository creation. This will allow us to pass rich data directly to repository creation without having to go through the config layer. It also allows us to be more explicit about the features requested during repository creation and provides a natural point to detect unhandled options influencing repository creation. The new code detects when unknown creation options are present and aborts in that case. .. api:: options can now be passed to influence repository creation The various instance() functions to spawn new peers or repository instances now receive a ``createopts`` argument that can be a dict defining additional options to influence repository creation. localrepo.newreporequirements() also receives this argument. Differential Revision: https://phab.mercurial-scm.org/D4535
Gregory Szorc -
r39585:089fc0db default
Show More
Name Size Modified Last Commit Author
/ hgext / infinitepush
README Loading ...
__init__.py Loading ...
bundleparts.py Loading ...
common.py Loading ...
fileindexapi.py Loading ...
indexapi.py Loading ...
schema.sql Loading ...
sqlindexapi.py Loading ...
store.py Loading ...

## What is it?

This extension adds ability to save certain pushes to a remote blob store
as bundles and to serve commits from remote blob store.
The revisions are stored on disk or in everstore.
The metadata are stored in sql or on disk.

## Config options

infinitepush.branchpattern: pattern to detect a scratchbranch, example
're:scratch/.+'

infinitepush.indextype: disk or sql for the metadata
infinitepush.reponame: only relevant for sql metadata backend, reponame to put in
sql

infinitepush.indexpath: only relevant for ondisk metadata backend, the path to
store the index on disk. If not set will be under .hg
in a folder named filebundlestore

infinitepush.storepath: only relevant for ondisk metadata backend, the path to
store the bundles. If not set, it will be
.hg/filebundlestore