The packages has to be installed by root but they would be installed
insecurely, owned by the uid of the unprivileged user that made the package.
The local user with that uid could thus write to /usr/local/bin/hg .
bdist_mpkg calls out to pax to create the package, but pax do apparently not
have the power to control what it is writing.
Instead, patch the pax files and set their uid fields to 0 before they are
wrapped in a dmg.
Before this patch, "reverting subrepo subrepo/path" lines in *.t test
files require "(glob)", because such lines are recognized as
"reverting path/to/managed/file" by "check-code.py".
On the other hand, "(glob)" for such "reverting ..." line is
recognized as useless by "runt-tests.py", because subrepo paths shown
in such lines are always normalized by "util.pconvert". And this
causes "no result code from test" warning.
As a preparation for discarding "(glob)" from such lines in subsequent
patch, this patch avoids warning against them, by adding negative
lookahead assertion "(?!subrepo )" to the regexp.
When "hg.bat" is invoked via interactive shell "cmd.exe" on Windows,
it can store own exit code into ERRORLEVEL correctly, regardless of
explicit "exit" statement in it: "cmd.exe" seems to hold ERRORLEVEL
updated by the last command in the batch file (= "python hg", in
"hg.bat" case).
On the other hand, "hg.bat" is invoked indirectly via
"subprocess.Popen" (e.g. shell alias, hooks, hgclient and so on), the
parent process always receives exit code 0 from spawned "hg.bat":
batch files on Windows seem not to be really spawned like as shell
scripts on UNIX, but to be executed in the "cmd.exe" process.
This patch returns exit code explicitly for indirect invocation.
"/b" should be specified for "exit" to prevent "cmd.exe" from being
terminated when "hg.bat" is invoked interactively from it.
This change touches every module in which repository.sopener was being used, and
changes it for the equivalent repository.svfs.
It should now be possible to remove localrepo.sopener.
When generating many new files into a set of many possible new directories,
there is the possibility that the same path is chosen as both file and
directory. How likely this is depends on the size of the dictionary used,
the generated directory structure and the number of generated files.
Now that we have decided on the use of 'name' instead of 'label' we rename this
function accordingly.
The old method 'debuglabelcomplete' has been left as a deprecated command so
that current scripts don't break.
The recursive addremove operation occurs completely before the first subrepo is
committed. Only hg subrepos support the addremove operation at the moment- svn
and git subrepos will warn and abort the commit.
I frequently find myself wanting to run hgweb in a production-like
environment, with a real HTTP server and multiple WSGI workers.
This patch introduces a Docker environment for running Mercurial
under Apache + mod_wsgi. With just a few command executions, it is
possible to spin up a Docker container running hgweb.
The container is tailored for Mercurial developers wanting to run
Mercurial from a source checkout. It is **not** meant to be something
suitable for production use.
The container provides a default hgweb environment with an empty
repository that allows pushes. You can thus start a container and push
your favorite repository there for quick testing.
The container is designed to allow customizations. Users can provide
their own hgweb configurations and mount existing directories containing
repositories into the container.
The behavior of the container and how to control things is documented in
the README.rst file.
The goal is to allow access to file outside ofthe store directory from the
transaction. The obvious target are the `bookmarks` file. But we can envision
usage for cache too.
We keep passing a main opener explicitly because a lot of code rely on this
default opener. The main opener (operating on store) is using an empty key ''.
We use a `formatter` object in the perf extensions. This allow the use of
formatted output like json. To avoid adding logic to create a formatter and pass
it around to the timer function in every command, we add a `gettimer` function
in charge of returning a `timer` function as simple as before but embedding an
appropriate formatter.
This new `gettimer` function also return the formatter as it needs to be
explicitly closed at the end of the command.
example output:
$ hg --config ui.formatjson=True perfvolatilesets visible obsolete
[
{
"comb": 0.02,
"count": 126,
"sys": 0.0,
"title": "obsolete",
"user": 0.02,
"wall": 0.0199398994446
},
{
"comb": 0.02,
"count": 117,
"sys": 0.0,
"title": "visible",
"user": 0.02,
"wall": 0.0250301361084
}
]
The merge tool configuration is an essential part of a good initial user
experience. 'make osx' installers and direct 'make' installation did not have
merge tool configuration. Now they have.
Note: The installer fixes for windows have been done blindly and might require
additional changes.
The phrase "revision or range" comes from a pre-revset era. Since the
documentation for ranges now is under the revset docs, and as a
helpful hint nudging users towards revsets, I think it's better to say
"revision or revset"
Before this patch, "import-checker.py" just replaces "/" in specified
filenames by ".". This makes modules for pure Python build belong to
"mercurial.pure" package, and prevents "import-checker.py" from
correctly checking about cyclic dependency in them.
This patch discards "pure" component from fully qualified name of such
modules.
To avoid discarding "pure" from the module name of standard libraries
unexpectedly, this patch allows "dotted_name_of_path" to discard
"pure" only from Mercurial specific modules, which are specified via
command line arguments.
Before this patch, "import-checker.py" assumes that the name of
Mercurial module recognized by "imported_modules" doesn't have package
part: for example, "util".
This is reason why "import-checker.py" always builds fully qualified
module name up relatively, if the given module doesn't belong to
standard Python library.
But in fact, modules imported in "from mercurial import XXXX" style
already have fully qualified name: for example, "mercurial.util"
module imported by "mercurial.parsers" is treated as
"mercurial.mercurial.util" because of building module name up
relatively.
This prevents "import-checker.py" from correctly checking about cyclic
dependency in them.
This patch avoids building module name up relatively, also if module
name starts with "mercurial.", to treat modules imported in "from
mercurial import XXXX" style correctly.
Augments the analyze command to additionally walk the repo's current
directory structure (or of any directory tree), counting how many files
appear in which paths. This data is saved in the repo model to be used
by synthesize, for creating an initial commit with many files.
This change is aimed at developing, testing and measuring scaling
improvements when importing/converting a large repository to mercurial.
Augments the synthesize command to use an additional parameter to the analyzed
repo model: the number of files in each directory at a given snapshot. Before
synthesizing history, an arbitrary number of files will be generated in a
distribution matching the analyzed directory structure.
Intended for developing, testing and measuring scaling improvements when
importing/converting a large repository to Mercurial.
This prepares for porting test-commandserver.py to .t test.
Though command-server test needs many Python codes, .t test will be more
readable than .py test thanks to inlined output.
If `hg analyze` is run on a revision set which contains no merges, then
`hg synthesize` will raise IndexError trying to select from p2distance,
which will be empty.
The existing roots(x - y) revset only considered the most recent 100
revisions. This was a good start. But expanding it to the full history
of the repository can dramatically increase execution time and thus
constitutes a useful benchmark.
