We need to make sure that if X is in the filecache then it's also in the
filecache owner's __dict__, otherwise it will go out of sync:
repo.X # first access to X, records stat info in
# filecache and updates __dict__
repo._filecache.clear() # removes X from _filecache but it's still in __dict__
repo.invalidate() # iterates over _filecache and removes entries
# from __dict__, but X isn't in _filecache, so
# it's kept in __dict__
repo.X # X is fetched from __dict__, bypassing the filecache
We call invalidate to remove properties from __dict__ because they're
possibly outdated and we'd like to check for a new version. Next time
the property is accessed the filecache mechanism checks the current stat
info with the one recorded at the last time the property was read, if
they're different it recreates the property.
Previously we refreshed the stat info on all properties in the filecache
when the lock is released, including properties that are missing from
__dict__. This is a problem because:
l = repo.lock()
repo.P # stat info S for P is recorded in _filecache
<changes are made to repo.P indirectly, e.g. underlying file is replaced>
# P's new stat info = S'
l.release() # filecache refreshes, records S' as P's stat info
At this point our filecache contains P with stat info S', but P's
version is from S, which is outdated.
The above happens during _rollback and strip. Currently we're wiping the
filecache and forcing everything to reload from scratch which works but
isn't the right solution.
The only way to access the branch of a changeset is currently to
create a changectx object and access its `branch()` method. Creating
a new Python object is costly and has a huge impact on code doing
heavy access to `branch()` (like branchmap).
This change introduces a new method on changelog that allows direct
access to the branch of a revision. See the next changeset for impact.
Creation of changectx objects is very slow, and they are not very
useful. We are going to drop them. The first step is to change the
function argument type.
We ensure all repositores created through `mercurial.hg.repository`
are "hidden" filtered. This is an even stronger enforcement than
86530c899687.
Citing Matt's response to changeset 86530c899687 installing filtering
in dispatch:
> Unfortunately, this means that code that doesn't go through dispatch (ie all
> those crazy misguided people using Mercurial as a library) are going to see
> these hidden changesets.
>
> Might be better to instead install the filter in localrepo construction by
> default and disable it in dispatch.
The existing workaround didn't work when no filename was specified.
If running in a context with warnings enabled and subsecond mtime it gave a
warning:
DeprecationWarning: use the name attribute
A situation with this case could happen after interrupting an update. Update
would fail with:
abort: No such file or directory: $TESTTMP/f/.hglf/sub2/large6
Update from a merge without using clean is not possible anyway, so this patch
takes a step in the right direction so it gets as far as reporting the right
error.
This patch is meant to make it easier for tools that wrap the mercurial
output (such as TortoiseHg) to find the "in subrepo MYSUBREPO" string that
(since 6c419dfc848c) is appended after subrepo error messages, particularly when
the mercurial output is translated to a non-English language.
The message remains the same but the '%s' that was used to prepend the original
error message in front of the 'in subrepo' string has been moved out of the
translatable string.
As an example of the usefulness of making it easy to look for "in subrepo
MYSUBREPO" strings, TortoiseHg looks for these strings in error messages in
order to "linkify them" (i.e. convert "MYSUBREPO" into alink to the
corresponding subrepo).
The original string made it hard for a tool such as TortoiseHg to look for the
translated string on mercurial's output because the translated string contained
the error message itself. This meant that a regular expression was required to
ignore the error message part. With this change TortoiseHg can just get the
translated "(in subrepo %s)" string, substitute %s for the subrepo path (which
it gets from the subrepo exception) and simply search for the resulting string
(no regular expression needed, or at least a much simpler regular expression
could be used).
Additionaly, the existing string could lead a translator mistakenly assume that
it was possible invert the order of the %s (error and subrepo path) fields,
which would not work because the string interpolation was position based.
Largefiles update would try to copy f to f.orig if there was a .hglf/f.orig .
That is in many many ways very very wrong, but it also caused an abort if f
didn't exist.
Now it only tries to copy f if it exists.
When extensions had an empty `testedwith` attribute the code tried to parse it
and failed. As a result the actual error were shallowed by a This crash.
We now treat empty strip as 'unknown'
This test started failing for me after midnight UTC on December
31st. Fixed it by specifying a date 7 years in the future more
precisely (rather than just adding 8 to the year and specifying
January 1st), which allows the test to pass both now and on 2012-12-01
at the same time.
The active bookmark were moved to the temporary commit. When the transaction
were rollbacked, the bookmark were lost.
We now temporarly disable the bookmark to prevent this effect.
The temporary commit created by amend update the dirstate. If the final commit
fails, we need to invalidate the change made to the dirstate, otherwise the
release of the wlock will write the dirstate created after the rollbacked
temporary commit.
This dirstate writing logic should probably be handled in the same object than
the transaction one. However such change are too big for stable.
posixpath.split() strips '/' from the dirname *unless it is the root*. This
patch reproduces this behavior in posix.split(). The old behavior causes a
crash when creating a file at the root of the repo with localrepo.wfile()
when the repo is at the root of the filesystem.
This changeset installs a broad filter on most repos used for
serving. This removes the need to use the `visiblehead`/`visiblebranchmap`
functions, and ensures that changesets we should not serve are in
fact never served.
We do not use filtering on hgweb yet, as there is still a number
of issues to solve there.
In their current state, revset calls can be very costly, as we test
predicates on the entire repository.
This change drops revset calls in favor of direct testing of the phase
of changesets.
Performance test on my Mercurial checkout
- 19857 total changesets,
- 1584 obsolete changesets,
- 13310 obsolescence markers.
Before:
! extinct
! wall 0.015124
After:
! extinct
! wall 0.009424
Performance test on a Mozilla central checkout:
- 117293 total changesets,
- 1 obsolete changeset,
- 1 obsolescence marker.
Before:
! extinct
! wall 0.032844
After:
! extinct
! wall 0.000066
In their current state, revset calls can be very costly, as we test
predicates on the entire repository.
This change drops a revset call in favor of direct testing of the
phase of changesets.
Performance test on my Mercurial checkout
- 19857 total changesets,
- 1584 obsolete changesets,
- 13310 obsolescence markers.
Before:
! suspended
! wall 0.014319
After:
! suspended
! wall 0.009559
Performance test on a Mozilla central checkout:
- 117293 total changesets,
- 1 obsolete changeset,
- 1 obsolescence marker.
Before:
! suspended
! wall 0.033373
After:
! suspended
! wall 0.000053
In their current state, revset calls can be very costly, as we test
predicates on the entire repository.
This change drops revset call in favor of direct testing of the
phase of changesets.
Performance test on my Mercurial checkout
- 19857 total changesets,
- 1584 obsolete changesets,
- 13310 obsolescence markers.
Before:
! unstable
! wall 0.017366
After this changes:
! unstable
! wall 0.008093
Performance test on a Mozilla central checkout:
- 117293 total changesets,
- 1 obsolete changeset,
- 1 obsolescence marker.
Before:
! unstable
! wall 0.045190
After:
! unstable
! wall 0.000032
In their current state, revset calls can be very costly, as we test
predicates on the entire repository. The "mutable" filter is used
during branch cache loading operation. We need to make it fast.
This change drops revset calls in favor of direct testing of the
phase of a changeset.
Performance test on my Mercurial checkout
- 19857 total changesets,
- 1646 mutable revision
Before:
! mutable
! wall 0.032405
After:
! mutable
! wall 0.001469
Performance test on a Mozilla central checkout:
- 117293 total changesets,
- 1 mutable changeset,
Before:
! mutable
! wall 0.188636
After:
! mutable
! wall 0.000022
In their current state, revset calls can be very costly, as we test
predicates on the entire repository. The "unserved" filter is used
in multiple applications, and in particular in some branch cache
loading operations. We need to make it fast.
This change drops revset calls in favor of direct testing of the
phase of a changeset.
Performance test on my Mercurial checkout
- 19857 total changesets,
- 1584 obsolete changesets,
- 13310 obsolescence markers.
Before:
! unserved
! wall 0.030477
After:
! unserved
! wall 0.011844
Performance test on a Mozilla central checkout:
- 117293 total changesets,
- 1 obsolete changeset,
- 1 obsolescence marker.
Before:
! unserved
! wall 0.111259
After:
! unserved
! wall 0.000084
