We're going to support the filemerge code resolving change/delete conflicts in
upcoming patches. Some of these resolutions require that the dirstate be
modified. Modifying the dirstate directly from in here would be (a) a pretty
bad layering violation and (b) wrong because all dirstate removals should
happen before adds. So in this and upcoming patches we're instead going to pass
whether the file is deleted up to merge.mergestate, then in there figure out
what dirstate action needs to be taken.
We introduce a new record type, 'C', to indicate change/delete conflicts. This
is a separate record type because older versions of Mercurial will not be able
to handle these conflicts.
We aren't actually storing any change/delete conflicts yet -- that will come in
future patches.
Currently strip works with a single bookmark,
the changes in this patch modifies the strip module
to work with a list of bookmarks
Building on this we can take a list of bookmarks as input
and remove all of them in a single go
File matching is done by applying the matcher to all elements in the 'file'
field of all changesets in the repository. This requires to read/parse all
changesets in the repository and do a lot of matching. However about 1/3 of the
time of the function is used to create 'changectx' object and retrieve their
'file' field.
This is far too much overhead so we are skipping the changectx layer and
directly access the data from the changelog. This provide use significant speed
up:
repository: mozilla central 252524 revisions
command: hg perfrevset '_matchfiles("p:browser")'
Before: 15.899687s
After: 10.011705s
Slowdown is even more significant if you have a lot of namespace that slowdown
lookup.
The time is now spent with this approximate repartition:
Matcher: 20%
regexp matching: 10%
changelog.read: 80%
reading revision: 60%
checking hash: 15%
decompression: 15%
reading chunk: 30%
changelog parsing: 20%
decoding to local: 10%
The next easy win is probably to have more of the changelog stack implemented
using the CPython api.
This works around a bug in older Mercurial versions' handling of the v2 merge
state.
We also add a bunch of tests that make sure that
(1) we correctly abort when the merge state has an unsupported record type
(2) aborting the merge, rebase or histedit continues to work and clears out the
merge state.
The merge from stable into default was semantically incomplete -- a couple of
changes in preceding code had to be rewritten here.
This code only triggers for change/delete conflicts, so we can't test it yet.
We will soon be able to do it, though.
Help of status cmd defines status file of 'missing', what is
called in fileset 'deleted'. To stay consistent this patch
introduces missing() predicate which in fact is alias to
'deleted'.
_siblings is a helper that is used for displaying changeset parents and
children in hgweb. Before, when it was a simple generator, it couldn't tell its
length without being consumed, and that required a special case when preparing
data for changeset template (see 3468fd599ef4).
Let's make it into a class (similar to templatekw._hybrid) that allows len(...)
without side-effects.
This is too low-level to be the top-level documentation for mergestate. We're
restricting the top-level documentation to only be about what consumers of the
mergestate and anyone extending it need to care about.
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.
