Summary:
The `RE2SRC` environment variable needs to be set at both `%build` and
`%install` steps. I didn't notice this issue because `build/re2-...` happened
to exist in my working copy when testing using `make local`.
Reviewed By: markbt
Differential Revision: D9528452
fbshipit-source-id: 1201c5bca06ac6393e518a8adea176cc829c467b
Summary:
If the user provides RE2SRC, do not download re2 from the predefined locations.
In rpmbuild process, the hg subrepo was archived and copied to a nested
subdirectory before the actual building. That means Makefile cannot find lfs.py
correctly and will try to download re2 from GitHub, which would break the build.
However, the rpmspec downloads, extracts, and sets RE2SRC, which should be
respected instead.
Change Makefile to skip downloading re2 if RE2SRC is set to non-default location.
Reviewed By: singhsrb
Differential Revision: D9525885
fbshipit-source-id: 0cbbe7cde61d8d7e8cd79a64fa0231a4089d7ab3
Summary:
This script takes care of the "one-time" setup. So the following things
would work:
- make local
- locally built "hg"
- tests/run-tests.py
Targing Windows (main goal), OSX, and CentOS.
Other scripts or hacks doing similar things are removed.
Reviewed By: phillco
Differential Revision: D9506352
fbshipit-source-id: dbc47e11f6988224c7c2cb59fb36b75ba7f3704b
Summary: This ensures all native components are built so gendoc.py can use them.
Reviewed By: singhsrb
Differential Revision: D9500859
fbshipit-source-id: 64154a5c1ce46abc4792a69aa1ea6d537ef9bdca
Summary:
This causes `make local` to build the new binary, copy the result into the
`.../hg` dir and rename it into `hg.rust` (while `hgmain` seems like a good
crate name, it seems like the binary should be called `hg.rust`, at least for
now)
Reviewed By: quark-zju
Differential Revision: D9218057
fbshipit-source-id: 49a0e09ae78b8cdb64c7158da3bb4179a47d4af9
Summary:
A recent refactor changed the location of the lfs helper, but a number
of paths weren't correct so this broke make local. This fixes them.
Reviewed By: singhsrb
Differential Revision: D8922233
fbshipit-source-id: 90b2997c702aabb352052a410d82554dfa083526
Summary:
We need to tweak users of `lfs` to (a) use if from the new location (b) pass
`-l` if `lfs.py` is used on the command line
Reviewed By: quark-zju
Differential Revision: D8894564
fbshipit-source-id: 652b0b4eba00fd1361f10b41a4c749ad4df7bb5f
Summary:
On OSX developers kept having to set their $PATH or change the make
file to actually build against the homebrew python. Let's build against it by
default if it exists.
Reviewed By: ryanmce
Differential Revision: D7791395
fbshipit-source-id: c69e41a469c5f94825814b4b30bc8ea144112167
Summary:
These stats are hard-coded for now but will in a future diff be fetched from a regularly-updated source.
```
fbclone fbsource --dry-run
usage: fbclone REPO [options]
fbclone: error: fbsource is too large to clone without a sparse profile
Please use one of the following profile switches:
--fbandroid: The full FBAndroid profile, for general development on Android apps.
file count: 644324 (35.83%) size 10.3 GB
--fbcode: The full FBCode profile, for general development on backend code.
file count: 950490 (52.85%) size 14.8 GB
--fbobjc: The full FBObjC profile, for general development on iOS apps.
file count: 620154 (34.48%) size 9.18 GB
--xplat: The base profile for xplat development, separate from other profiles that include xplat
file count: 269858 (15.01%) size 4.41 GB
Or use --everything to get a full-size working copy
```
Differential Revision: D7502448
fbshipit-source-id: e37e4e31d355251e9dd2c390e3de7643fa38b80b
Summary:
There are tests in fb/tests we don't run as part of the test suite. Update the makefile and add buck infrastructure to run them.
- Update the test-common-commands-hg.t test
- Re-generate the fbcode/.hgignore file from the updated .gitignore
Reviewed By: quark-zju
Differential Revision: D7584511
fbshipit-source-id: d85800dccf0eb569a68db4b9e1d9796e3d7ac957
Summary:
Moves the remotefilelog extension into hgext/ and it's tests into
tests/.
I did not fix up all the check-module errors, since it's a ton of work for
very little impact at this point.
Test Plan: make local && ./run-tests.py
Reviewers: #mercurial
Differential Revision: https://phabricator.intern.facebook.com/D6680030
Summary:
cdatapack depends on sha1detectcoll, so let's add the library to setup.py before
we add cdatapack.
Test Plan:
hg purge --all && make local && cd tests/ && ./run-tests.py -S -j 48
Verified sha1dc was in the build output and the tests passed.
Reviewers: quark, #mercurial
Reviewed By: quark
Differential Revision: https://phabricator.intern.facebook.com/D6676405
Signature: 6676405:1515444508:2da65c6c3a18267a1d3c151c8e9acf60b674ffc2
This rule is no longer useful because chg daemon may be killed and respawned
per config/environment hash. We can't reliably run a daemon in foreground.
Before this patch, HGVER would be evaluated at the beginning of the make
execution, and would be unset because build/mercurial/ doesn't exist yet
at that point. Now we compute the version after the `make install` run
has completed.
This is backported to stable from 8626b44516c1, but that revision had an
error in the shell invocation syntax.
The only version strings that are changed are the ones baked into the
.pkg - hg's self-reported version string doesn't change, so users will
still see our mostly-pip-compatible version strings.
For reference, the part of our versioning setup that's not PEP440
compatible is the RC releases - those should be .rc0 insted of
-rc. It's too late to change that for the 4.3 cycle, so I'll worry
about fixing that during the 4.4 cycle.
The way HGVER is evaluated now, it'll be evaluated at the beginning of the
make execution - with this change, it's evaluated when it gets to that command,
at which point the version file it's looking for is sure to exist and be
up-to-date.
Differential Revision: https://phab.mercurial-scm.org/D224
The contrib/zsh_completion file itself says to name it _hg.
With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)`
in their zshrc, it will create a shell function named `hg` that will hide the
actual hg command and make hg unusable.
Separately from that though, the underscore prefix makes it actually work. The
zsh man page states:
The convention for autoloaded functions used in completion is that they
start with an underscore
This does not seem to just be a "convention", though. With the ill-advised line
removed from my zshrc and the file named
`/usr/local/share/zsh/site-functions/hg` (without the underscore), these
completions did not seem to get loaded and the ones from the zsh installation
were loaded instead. If I renamed them to be
`/usr/local/share/zsh/site-functions/_hg`, however, they were loaded.
I manually tested the above statement by starting a new zsh instance with the
file in `/usr/local/share/zsh/site-functions` with the following names:
- As `hg`, `which _hg_labels` did not show anything
- As `_hg`, `which _hg_labels` showed the expected function.
To quote `man 1 pkgbuild`:
--filter filter-expression
By default, --root will include the entire contents of the
given root-path in the package payload, except for any .svn
or CVS directories, and any .DS_Store files. You can override
these default filters by specifying one or more --filter
options. Each filter-expression is an re_format(7)
``extended'' expression: any path in the root which matches
any of the given expressions will be excluded from the pack-
age payload. (Note that specifying even one --filter inhibits
the default filters, so you must respecify the default fil-
ters if you still want them to be used.)
It turns out the default filter these days *also* includes .git and
.hg. Notice how that filter expression is a regular expression? That
(presumably unintentionally) prevents a file named "chg" or "_hg" from
getting included in the distribution. Many many thanks to spectral@
for trying to include a _hg file which led us to figure this bug out.
Bug filed with Apple for this as rdar://problem/32437369, mentioning
both the gap in documentation and the wrong defaults.
Having linux wheels is going to helps system without compiler or python-dev
plus speed up the installation for everyone.
I followed the manylinux example repository
https://github.com/pypa/python-manylinux-demo
to add a make target (build-linux-wheels) using
official docker image to build python 2 linux wheels
for mercurial. It generates Python 2.6 and Python 2.7 for both
32 and 64 bits architectures.
I had to blacklist several test cases for various reasons:
* test-convert-git.t and test-subrepo-git.t because of the git version
* test-patchbomb-tls.t because of warning using tls 1.0
It's likely because the docker image is based on centos 5.0 and
openssl is outdated.
The contrib/zsh_completion file itself says to name it _hg.
With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)`
in their zshrc, it will create a shell function named `hg` that will hide the
actual hg command and make hg unusable.
Separately from that though, the underscore prefix makes it actually work. The
zsh man page states:
The convention for autoloaded functions used in completion is that they
start with an underscore
This does not seem to just be a "convention", though. With the ill-advised line
removed from my zshrc and the file named
`/usr/local/share/zsh/site-functions/hg` (without the underscore), these
completions did not seem to get loaded and the ones from the zsh installation
were loaded instead. If I renamed them to be
`/usr/local/share/zsh/site-functions/_hg`, however, they were loaded.
I manually tested the above statement by starting a new zsh instance with the
file in `/usr/local/share/zsh/site-functions` with the following names:
- As `hg`, `which _hg_labels` did not show anything
- As `_hg`, `which _hg_labels` showed the expected function.
To quote `man 1 pkgbuild`:
--filter filter-expression
By default, --root will include the entire contents of the
given root-path in the package payload, except for any .svn
or CVS directories, and any .DS_Store files. You can override
these default filters by specifying one or more --filter
options. Each filter-expression is an re_format(7)
``extended'' expression: any path in the root which matches
any of the given expressions will be excluded from the pack-
age payload. (Note that specifying even one --filter inhibits
the default filters, so you must respecify the default fil-
ters if you still want them to be used.)
It turns out the default filter these days *also* includes .git and
.hg. Notice how that filter expression is a regular expression? That
(presumably unintentionally) prevents a file named "chg" or "_hg" from
getting included in the distribution. Many many thanks to spectral@
for trying to include a _hg file which led us to figure this bug out.
Bug filed with Apple for this as rdar://problem/32437369, mentioning
both the gap in documentation and the wrong defaults.
The zsh location appears to be on the default $fpath for zsh. bash, on
the other hand, appears to have no default location for completion
scripts, so we follow the lead of Apple's Git distribution and select
a semi-arbitrary place in /usr/local for the file.
Ubuntu 15.10 (Wily Werewolf) came out on October 22, 2015 and reached end of
life on July 28, 2016 [1]. Users were encouraged to upgrade to 16.04 (Xenial).
PPA doesn't allow new uploads targeting 15.10 anymore.
[1]: https://wiki.ubuntu.com/Releases
