We've globablly forced stat to return integer times which agrees with
our extension code, so this is no longer needed.
This speeds up status on mozilla-central substantially:
$ hg perfstatus
! wall 0.190179 comb 0.180000 user 0.120000 sys 0.060000 (best of 53)
$ hg perfstatus
! wall 0.275729 comb 0.270000 user 0.210000 sys 0.060000 (best of 36)
Alternate fix for this issue which avoids putting extra function calls
and exception handling in the fast path.
For almost all purposes, integer timestamps are preferable to
Mercurial. It stores integer timestamps in the dirstate and would thus
like to avoid doing any float/int comparisons or conversions. We will
continue to have to deal with 1-second granularity on filesystems for
quite some time, so this won't significantly hinder our capabilities.
This has some impact on our file cache validation code in that it
lowers timestamp resolution. But as we still have to deal with
low-resolution filesystems, we're not relying on this anyway.
An alternate approach is to use stat[ST_MTIME], which is guaranteed to
be an integer. But since this support isn't already in our extension,
we can't depend on it being available without adding a hard Python->C
API dependency that's painful for people like yours truly who have
bisect regularly and people without compilers.
This patch avoids unnecessary conflicts to resolve during rebase for the users
of changeset evolution.
This patch modifies rebase to skip obsolete commits with no successor.
It introduces a new rebase state 'revpruned' for these revisions that are
being skipped and a new message to inform the user of what is happening.
This feature is gated behind the config flag experimental.rebaseskipobsolete
When an obsolete commit is skipped, the output is:
note: not rebasing 7:360bbaa7d3ce "O", it has no successor
So far pullrebase function has always returned None value, no matter
what orig function returned. This behaviour made impossible for
pull to change returned value from mercurial process (it has always
ended with 0 value by default). This patch makes pullrebase returning
with returned value from orig.
Previously, we'd restore the .orig file after the premerge is complete but
before the merge was complete. This would lead to the .orig file potentially
containing merge conflict markers in it, as a leftover from the last merge
attempt.
sortdict internally maintains a list of keys in insertion order. When a
key is replaced via __setitem__, we .remove() from this list. This
involves a linear scan and array adjustment. This is an expensive
operation.
The tags reading code was calling into sortdict.__setitem__ for each tag
in a read .hgtags revision. For repositories with thousands of tags or
thousands of .hgtags revisions, the overhead from list.remove()
noticeable.
This patch creates a new sortdict() so __setitem__ calls don't incur a
list.remove.
This doesn't appear to have any performance impact on my Firefox
repository. But that's only because tags reading doesn't show up in
profiles to begin with. I'm still waiting to hear from a user with over
10,000 tags and hundreds of heads on the impact of this patch.
4bc805f938a0 made 'bmstore.write()' transaction sensitive, to restore
original bookmarks correctly at failure of a transaction.
For example, shelve and unshelve imply steps below:
before 4bc805f938a0:
1. move active bookmark forward at internal rebasing
2. 'bmstore.write()' writes updated ones into .hg/bookmarks
3. rollback transaction to remove internal commits
4. restore updated bookmarks manually
after 4bc805f938a0:
1. move active bookmark forward at internal rebasing
2. 'bmstore.write()' doesn't write updated ones into .hg/bookmarks
(these are written into .hg/bookmarks.pending, if external hook
is spawn)
3. rollback transaction to remove internal commits
4. .hg/bookmarks should be clean, because it isn't changed while
transaction running: see (2) above
But if shelve or unshelve is executed in the repository created with
"shared bookmarks" ("hg share -B"), this doesn't work as expected,
because:
- share extension makes 'bmstore.write()' write updated bookmarks
into .hg/bookmarks of shared source repository regardless of
transaction activity, and
- intentional transaction failure at the end of shelve/unshelve
doesn't restore already updated .hg/bookmarks of shared source
This patch makes share extension wrap 'bmstore._writerepo()' instead
of 'bmstore.write()', because the former is used to actually write
bookmark changes out.
The cut and head utilities on Solaris have weird differences from the GNU
versions. The f helper script does a dump more nicely than those tools,
anyway.
There are make targets for building mercurial packages for various
distributions using docker. One of the preparation steps before building is to
create inside the docker image a user with the same uid/gid as the current user
on the host system, so that the resulting files have appropriate
ownership/permissions.
It's possible to run `make docker-<distro>` as a user with uid or gid that is
already present in a vanilla docker container of that distibution. For example,
issue4657 is about failing to build fedora packages as a user with uid=999 and
gid=999 because these ids are already used in fedora, and groupadd fails.
useradd would fail too, if the flow ever got to it (and there was a user with
such uid already).
A straightforward (maybe too much) way to fix this is to allow non-unique uid
and gid for the new user and group that get created inside the image. I'm not
sure of the implications of this, but marmoute encouraged me to try and send
this patch for stable.
The _filefoldmap is not updated in when files are deleted from dirstate. In the
case where the file with the same but differently cased name is added afterwards
it renders _filefoldmap incorrect. Those steps must occur to for a problem to
reproduce:
- call status (with listunknown=True),
- update working rectory to a commit which does a casefolding change (A -> a)
- call status again (it will show the file "a" as deleted)
Unfortunately I'm unable to write a test for it because I don't know any
core-mercurial command able to reproduce those steps.
The bug was originally spotted when hgwatchman was enabled. It caused the
changeset contents change during hg rebase (one file unrelarted to changeset
was deleted in it after rebase).
The hgwatchman is able to hit it because when hgignore changes the hgwatchmans
overridestatus is calling original status with listunknown=True.
Multiple threads might attempt to check links with the same temporary
name. This would cause one side to get an EEXIST error and wrongly
fail the support check. Here, we simply retry if our temporary name
exists.
The previous changeset is a simpler way of fixing issue4934 without changing the
spirit of the code. We can remove the dual call to 'delayupdate' but we keep the
tests to show that the issue is still fixed.
The 'prechangegroup' interfere with 'delayupdate' logic because it trigger the
one time call of 'changelog._writepending' (see issure4934). There is no reason
not to call that hook before setting up 'delayupdate' so we move the call a bit
earlier to avoid interference.
The try finally is here to ensure we release the just-created transaction.
Therefore we should not do half a dozen operations before actually entry the try
scope.
As the fromlist gives the names of sub-modules, they should be searched in
the parent directory of the package's __init__.py, which is level=1.
I got the following error by rewriting hgweb to use absolute_import, where
the "mercurial" package is referenced as ".." (level=2):
ValueError: Attempted relative import beyond toplevel package
I know little about the import mechanism, but this change seems correct.
Before this patch, the following code did import the os module with no error:
from mercurial import demandimport
demandimport.enable()
from mercurial import os
print os.name
Because parsers.c does not define PY_SSIZE_T_CLEAN, "s#" format requires
(const char*, int), not (const char*, Py_ssize_t).
https://docs.python.org/2/c-api/arg.html
This error had no problem before 7d13be5f72c2, where datalen wasn't used.
But now fm1readmarkers() fails with "overflow in obsstore" on Python 2.6.9
(amd64) because upper bits of datalen seem to be filled with 1, making it
a negative integer.
This problem seems not visible on our Python 2.7 environment because upper
bits happen to be filled with 0.
Changeset e7b51de6e8eb alters the 'HG_PENDING' mechanism to be "always" there.
This change is made under the assumption than we previously did it only when
"writepending() actually wrote something". This assumption was wrong,
'writepending()' informs of pending changes the first time something is written
and for all following calls. We back this change out to restore the former
behavior, which was already correct.
We need to call delayupdate again after writing to the changelog.
Otherwise the prechangegroup hook consumes the delayupdate subscription and
future hooks don't see the pending changes (see issue 4934 for more details).
Adds a test that triggers the prechangegroup hook before the pretxnchangegroup
hook and verifies that the output of pretxnchangegroup doesn't change.
Previously we would only include HG_PENDING in the hook args if the
transaction's writepending() actually wrote something. This is a bad criteria,
since it's possible that a previous call to writepending() wrote stuff and the
hooks want to still see that.
The solution is to always have hooks execute within the scope of the pending
changes by always putting HG_PENDING in the environment.
The SSH peer class accesses wireproto.commands[cmd] as part of encoding
command arguments. Previously, the wire protocol command was defined in
the clonebundles extension. If the client didn't have this extension
enabled (which it likely doesn't since it is meant as a server-side
extension), then clients attempting to clone via ssh:// would get a
crash due to a KeyError accessing wireproto.commands['clonebundles']
when cloning from a server that is advertising clone bundles.
Moving the definition of the wire protocol command to wireproto.py makes
this problem go away.
A side effect of this code move is servers will always respond to
"clonebundles" wire protocol command requests. This should be fine: the
server will return an empty response unless a clone bundles manifest
file is present and clients shouldn't call the command unless the server
is advertising the capability, which only happens if the clonebundles
extension is enabled and the manifest file exists.
As JSON string is known to be a unicode, we should try round-trip conversion
for localstr type. This patch tests localstr type explicitly because
encoding.fromlocal() may raise Abort for undecodable str, which is probably
not what we want. Maybe we can refactor json filter to use encoding module
more later.
Still "{desc|json}" can't round-trip because showdescription() modifies a
localstr object.
This patch replaces old "DEPRECATED" msgid by "(DEPRECATED)" if that .po
file does not have "(DEPRECATED)" but have "... (DEPRECATED)".
It is necessary to hide deprecated options correctly.
Because f94973e0eefb requires the msgstr of "(DEPRECATED)", old *.po files
must be blamed. Using "DEPRECATED" would just hide the error.
For example, "LANG=da_DK.UTF-8 hg help serve" fails to hide deprecated
options right now, but check-translation.py couldn't detect it because
da.po has outdated translation of "DEPRECATED".
With this patch, mergestate.clean() will no longer abort when it encounters an
unsupported merge type. However we hold off on testing it until backwards
compatibility is in place.
We would normally use the read() constructor, but in this case it's fine
because
- we implement our own reading layer, so the extra parsing done by
read() is unnecessary
- read() can raise an exception for unsupported merge state records,
but here we'd like to handle that separately
- debugmergestate needs to be privy to mergestate internals anyway
Removes the named arguments and replaces them by accessing opts. This will be
used in the next patch in the series because we'll be adding more flags to
debugdirstate
On my machine, whenever I run all test with a high -j value, test-convert-git.t
would consistently fail by displaying an estimate. This patch removes that value
from the output.
Before this patch, mq was using repo._bookmarks.write.
This patch replaces this code with the recommended way of saving bookmarks
changes: repo._bookmarks.recordchange.
Before this patch, making a commit on a local repo could move a bookmark and
both operations would not be grouped as one transaction. This patch makes both
operations part of one transaction. This is necessary to switch to the new api
to save bookmarks repo._bookmarks.recordchange if we don't want to change the
current behavior of rollback.
Dirstate change happening after the commit is done is now part of the
transaction mentioned above. This leads to a change in the expected output of
several tests.
The change to test-fncache happens because both lock are now released in the
same finally clause. The lock release is made explicitly buggy in this test.
Previously releasing lock would crash triggering release of wlock that crashes
too. Now lock release crash does not directly result in the release of wlock.
Instead wlock is released at garbage collection time and the error raised at
that time "confuses" python.
See previous patch for why we're doing this.
We do this with a bit of care -- it would be bad form for 'hg summary' to abort
completely if we encounter an unsupported merge record. Instead just warn about
that and continue with the rest of the summary.
