Summary: Also change the internal API so it no longer accepts the "heads" argument.
Reviewed By: ryanmce
Differential Revision: D6745865
fbshipit-source-id: 368742be49b192f7630421003552d0a10eb0b76d
Summary:
`lfs` is the better large file solution. `largefiles` is rarely used, and
its implementation is less clean. So let's remove it.
Test Plan:
Ran all tests. A subrepo test was removed instead of cleaned up since the
longer term plan is to also drop subrepo support.
Reviewers: phillco, #mercurial
Reviewed By: phillco
Differential Revision: https://phabricator.intern.facebook.com/D6740361
Signature: 6740361:1516225594:555e3803571ad05e0434021897a2823ac99347ae
This is the same mechanism in place for largefiles, and solves several problems
working with multiple local repositories. The existing largefiles method is
reused in place, because I suspect that there are other functions that can be
shared. If we wait a bit to identify more before `hg cp lfutil.py ...`, the
history will be easier to trace.
The push between repo14 and repo15 in test-lfs.t arguably shouldn't be uploading
any files with a local push. Maybe we can revisit that when `hg push` without
'lfs.url' can upload files to the push destination. Then it would be consistent
for blobs in a local push to be linked to the local destination's cache.
The cache property is added to run-tests.py, the same as the largefiles
property, so that test generated files don't pollute the real location. Having
files available locally broke a couple existing lfs-test-server tests, so the
cache is cleared in a few places to force file download.
If this feature is enabled, early options are parsed using the global options
table. As the parser stops processing options when non/unknown option is
encountered, it won't mistakenly take an option value as a new early option.
Still "--" can be injected to terminate the parsing (e.g. "hg -R -- log"), I
think it's unlikely to lead to an RCE.
To minimize a risk of this change, new fancyopts.earlygetopt() path is enabled
only when +strictflags is set. Also the strict parser doesn't support '--repo',
a short for '--repository' yet. This limitation will be removed later.
As this feature is backward incompatible, I decided to add a new opt-in
mechanism to HGPLAIN. I'm not pretty sure if this is the right choice, but
I'm thinking of adding +feature/-feature syntax to HGPLAIN. Alternatively,
we could add a new environment variable. Any bikeshedding is welcome.
Note that HGPLAIN=+strictflags doesn't work correctly in chg session since
command arguments are pre-processed in C. This wouldn't be easily fixed.
Yuja's comment on the original obsfate about how we would translate obsfate
and the recent discussions about exposing users to new concepts and names lead
have led me to think that 'obsfate' should be treated as internal jargon. End-
users should not be aware of obsfate, so we replace 'obsfate' by 'obsolete' in
changeset_printer.
It will be easier to understand for end-users, easier to translate and closer
to the original Evolve obsfate output.
I'm aware it's extremely late in the cycle but I think it's an UX improvement
for the end-users.
Differential Revision: https://phab.mercurial-scm.org/D1189
Extract 'experimental.evolution' = createmarkers as
'experimental.evolution.createmarkers'.
We keep the new option in the 'experimental.evolution' namespace in order to
stay coherent with other options ('experimental.evolution.bundle-obsmarker'
and 'experimental.evolution.track-operation') ease the renaming as possibly
'evolution.createmarkers'.
Differential Revision: https://phab.mercurial-scm.org/D1149
Having an obsfate by default in log will be useful for users to understand why
they have obsolete and unstable changesets. Obsfate will only be shown for
obsolete changesets, which only happens if people opt-in to experimental feature.
But when obsolete changeset are visible, it is very useful to understand where
they are. Having it in log could be sufficient for most people, so they don't
have to learn a new command (like obslog which is itself useful in case of
divergences).
For example, when pulling and working directory parent become obsolete:
$ hg pull
...
working directory parent is obsolete! (f936c1697205)
This message comes from the Evolve extension.
Obsfate would comes handy:
$ hg log -G
o changeset: 2:6f91013c5136
| tag: tip
| parent: 0:4ef7b558f3ec
| user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| summary: A
|
| @ changeset: 1:f936c1697205
|/ user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| obsfate: rewritten using amend as 2:6f91013c5136
| summary: -A
|
o changeset: 0:feb4dd822b8c
user: Boris Feld <boris.feld@octobus.net>
date: Tue Oct 09 16:00:00 2017 +0200
summary: ROOT
And once we update, we don't have an obsolete changeset in the log anymore so
we don't show obsfate anymore, most users won't see obsfate often if they
don't have obsolete changeset often:
@ changeset: 2:6f91013c5136
| tag: tip
| parent: 0:4ef7b558f3ec
| user: Boris Feld <boris.feld@octobus.net>
| date: Mon Oct 09 16:00:27 2017 +0200
| summary: A
|
o changeset: 0:feb4dd822b8c
user: Boris Feld <boris.feld@octobus.net>
date: Tue Oct 09 16:00:00 2017 +0200
summary: ROOT
When merging, check for any path conflicts introduced by the manifest
merge and rename the conflicting file to a safe name.
Differential Revision: https://phab.mercurial-scm.org/D784
This helps the import checker notice when a Python heredoc has
ended. It's not perfect, but it gets nasty quick and I think the
better fix would be to add a real parser for .t-tests, which will have
to wait.
evolution* config has been rewritten in stabilization* in the previous patch,
update tests file to use the new names.
Differential Revision: https://phab.mercurial-scm.org/D249
The initial attempt was to discard cache when appropriate, but it appears
to be error prone. We had to carefully inspect all places where audit() is
called e.g. without actually updating filesystem, before removing files and
directories, etc.
So, this patch disables the cache of audited paths by default, and enables
it only for the following cases:
- short-lived auditor objects
- repo.vfs, repo.svfs, and repo.cachevfs, which are managed directories
and considered sort of append-only (a file/directory would never be
replaced with a symlink)
There would be more cacheable vfs objects (e.g. mq.queue.opener), but I
decided not to inspect all of them in this patch. We can make them cached
later.
Benchmark result:
- using old clone of http://selenic.com/repo/linux-2.6/ (38319 files)
- on tmpfs
- run HGRCPATH=/dev/null hg up -q --time tip && hg up -q null
- try 4 times and take the last three results
original:
real 7.480 secs (user 1.140+22.760 sys 0.150+1.690)
real 8.010 secs (user 1.070+22.280 sys 0.170+2.120)
real 7.470 secs (user 1.120+22.390 sys 0.120+1.910)
clearcache (the other series):
real 7.680 secs (user 1.120+23.420 sys 0.140+1.970)
real 7.670 secs (user 1.110+23.620 sys 0.130+1.810)
real 7.740 secs (user 1.090+23.510 sys 0.160+1.940)
enable cache only for vfs and svfs (this series):
real 8.730 secs (user 1.500+25.190 sys 0.260+2.260)
real 8.750 secs (user 1.490+25.170 sys 0.250+2.340)
real 9.010 secs (user 1.680+25.340 sys 0.280+2.540)
remove cache function at all (for reference):
real 9.620 secs (user 1.440+27.120 sys 0.250+2.980)
real 9.420 secs (user 1.400+26.940 sys 0.320+3.130)
real 9.760 secs (user 1.530+27.270 sys 0.250+2.970)
Pypy 5.6.0 saves cached bytecode files in __pycache__ directory, clean them in
tests to fix loading old test extensions code.
Doing so should also helps for Python3.x migration.
Now that we have the default-date by default and all code have been updated,
remove the old commands alias that forced the date as they are not longer
useful.
Writing tests now should be easier for everyone now that all dates should be
stable.
cmdutil.command wasn't a member of the registrar framework only for a
historical reason. Let's make that happen. This patch keeps cmdutil.command
as an alias for extension compatibility.
Previously, we only set web.ipv6 if IPv6 is used, but not on the IPv4 case.
Since we already have set web.address, it makes sense to move "web.ipv6" out
from "extra config options".
Previously, "hg serve" will listen on "", which is not clear which interface
it will actually listen on - it could listen on all interfaces (ex. 0.0.0.0
on IPv4).
The run-tests.py script only checks "localhost" for available ports. So
let's make it the same for "hg serve" by explicitly setting "web.address" to
"localhost".
This resolves some IPv6 EADDRINUSE errors.
As explained by the previous patch, we need to set "web.ipv6=True" if we
decide to use IPv6. Otherwise "hg serve" will still try to listen on IPv4.
This patch makes it so by appending web.ipv6 to "extra configs".
This patch was tested in a Linux system with IPv6, by the following steps:
1. Change hgweb/server.py temporarily to write a file if
IPv6HTTPServer.__init__ is called.
2. run-tests.py -l --keep-tmpdir test-serve.t
3. Check the generated .hgrc, make sure it sets web.ipv6=1.
4. Check the log file to make sure IPv6HTTPServer.__init__ is called.
readline() returns '' only when EOF is encountered, in which case, Python's
getpass() raises EOFError. We should do the same to abort the session as
"response expected."
This bug was reported to
https://bitbucket.org/tortoisehg/thg/issues/4659/
It was introduced by e0df29fe80bf to address command-server issues. After
that, I've made a complete fix by b096b3ac9391, so we don't need to replace
sys.stdio objects to protect the IPC channels.
This change means we no longer see data written to sys.stdout/err by an
in-process hook on command server. I think that's okay because the canonical
way is to use ui functions and in-process hooks should respect the Mercurial
API.
This will help Python 3 porting, where sys.stdout is TextIO but ui.fout is
BytesIO.
This patch includes addition of absolute_import and print_function to the
files where they are missing. The modern importing conventions are also followed.
In 'unix' mode, the server is typically detached from the console. Therefore
a client couldn't see the exception that occurred while instantiating the
server object.
This patch tries to catch the early error and send it to 'e' channel even if
the server isn't instantiated yet. This means the error may be sent before the
initial hello message. So it's up to the client implementation whether to
handle the early error message or error out as protocol violation.
The error handling code is also copied to chgserver.py. I'll factor out them
later if we manage to get chg passes the test suite.
Before this patch, revisions rollbacked at failure of previous
transaction might be visible at subsequent operations unintentionally,
if repoview object is reused even after failure of transaction:
e.g. command server and HTTP server are typical cases.
'repoview' uses the tuple of values below of unfiltered changelog as
"the key" to examine validity of filtered changelog cache.
- length
- tip node
- filtered revisions (as hashed value)
- '_delayed' field
'repoview' compares between "the key" of unfiltered changelog at
previous caching and now, and reuses filtered changelog cache if no
change is detected.
But this comparison indicates only that there is no change between
unfiltered 'repo.changelog' at last caching and now, but not that
filtered changelog cache is valid for current unfiltered one.
'repoview' uses "shallow copy" of unfiltered changelog to create
filtered changelog cache. In this case, 'index' buffer of unfiltered
changelog is also referred by filtered changelog.
At failure of transaction, unfiltered changelog itself is invalidated
(= un-referred) on the 'repo' side (see b7829fc79508 also). But
'index' of it still contains revisions to be rollbacked at this
failure, and is referred by filtered changelog.
Therefore, even if there is no change between unfiltered
'repo.changelog' at last caching and now, steps below makes rollbacked
revisions visible via filtered changelog unintentionally.
1. instantiate unfiltered changelog as 'repo.changelog'
(call it CL1)
2. make filtered (= shallow copy of) CL1
(call it FCL1)
3. cache FCL1 with "the key" of CL1
4. revisions are appended to 'index', which is shared by CL1 and FCL1
5. invalidate 'repo.changelog' (= CL1) at failure of transaction
6. instantiate 'repo.changelog' again at next operation
(call it CL2)
CL2 doesn't have revisions added at (4), because it is
instantiated from '00changelog.i', which isn't changed while
failed transaction.
7. compare between "the key" of CL1 and CL2
8. FCL1 cached at (3) is reused, because comparison at (7) doesn't
detect change between CL1 at (1) and CL2
9. revisions rollbacked at (5) are visible via FCL1 unintentionally,
because FCL1 still refers 'index' changed at (4)
The root cause of this issue is that there is no examination about
validity of filtered changelog cache against current unfiltered one.
This patch discards filtered changelog cache, if its 'index' object
isn't shared with unfiltered one.
BTW, at the time of this patch, redundant truncation of
'00changelog.i' at failure of transaction (see b7829fc79508 for
detail) often prevents "hg serve" from making already rollbacked
revisions visible, because updating timestamps of '00changelog.i' by
truncation makes "hg serve" discard old repoview object with invalid
filtered changelog cache.
This is reason why this issue is overlooked before this patch, even
though test-bundle2-exchange.t has tests in similar situation: failure
of "hg push" via HTTP by pretxnclose hook on server side doesn't
prevent subsequent commands from looking up outgoing revisions
correctly.
But timestamp on the filesystem doesn't have enough resolution for
recent computation power, and it can't be assumed that this avoidance
always works as expected.
Therefore, without this patch, this issue might appear occasionally.
Because _phaserevs and _phasesets cache revision numbers, they must be
invalidated if there are new commits or stripped revisions. We could do
that by calling _phasecache.invalidate(), but it wasn't simple to be
integrated with the filecache mechanism.
So for now, phasecache will be recreated after repo.invalidate() if
00changelog.i was modified before.
If commit is aborted by pretxncommit hook, in-memory changelog and manifest
have entries that would be added. So they must be discarded on invalidate().
But the mechanism introduced by 071f71da2fe2 doesn't handle this case well.
It tries to mitigate the penalty of invalidate() by marking in-memory cache
as "clean" on unlock assuming that they are identical to the stored data.
But this assumption is wrong if stored data are rolled back by tr.abort().
This patch moves the hook to post-close action so that it will never be
triggered on abort.
This bug was originally reported to thg, which is only reproducible in
command-server process on unix, evolve disabled.
https://bitbucket.org/tortoisehg/thg/issues/4285/
Before this patch, repo could be set to None for wrong -R. It's okay for
commands that can reject repo=None, but the command server have a problem
because:
- it accepts repo=None for "unbound" mode
- and it reenters dispatch() where repo object is created for cwd by default
Test outputs are changed because the error is detected earlier. I think new
message is better than ".hg not found".
We have started to isolate extra usecases for developer-only output
that is not a warning. As the section has the fairly generic name
'devel' it makes sense to tuck them there. As a result, 'all' becomes
a bit misleading so we rename it to 'all-warnings'. This will break
some developer setups but the tests are still fine and developers will
likely spot this change.
This should help us to catch new locking order issues as soon as possible.
There are two harmless test updates (from the config change). Moreover, some
bundle2 tests are displaying warning for a legitimate reason. The use of pushkey
during the unbundle process may requires the 'wlock' after 'lock' (around the
whole unbundle process was taken). This is non-trivial to fix, so I better have
the check on, with the warning in the test than the check off. See issue4596 for
details.
This fixes a test failure introduced in 131ac757f996 on Windows and OS X, where
the cached largefile wasn't being deleted because the named .cache directory
didn't exist. It only existed on Linux because the test suite sets $HOME to the
directory of the test being run, and Linux uses $HOME/.cache by default.
Most of the other largefiles tests explicitly set this value at the top of their
scripts, but test-largefiles-update.t didn't pick that up when it was created.
Those scripts that do set a value will override this.
We could just set the parameter in the test-largefiles-update.t script, but
there are a few other non obvious tests that exercise largefiles too. These
largefiles end up being cached in the user's real cache, so proper hygiene
dictates that this not be left to each individual test script.
Because pipe-mode server uses stdio as IPC channel, other modules should not
touch stdio directly and use ui instead. However, this strategy is brittle
because several Python functions read and write stdio implicitly.
print 'hello' # should use ui.write()
# => ch = 'h', size = 1701604463 'ello', data = '\n'
This patch adds protection for such mistakes. Both stdio files and low-level
file descriptors are redirected to /dev/null while command server uses them.
The problem in commandserver was addressed by 766cfbe766dc, but it is tricky
to reuse ui.nontty option to disable echo back. Instead, this patch introduces
new option to enable echoing of prompt response.
Prompt echoing is changed to be off by default, which should avoid possible
breakage of output parsing in user scripts.
For now, this option is undocumented because it exists for internal use.
