Since it's highly use-case dependent how template should be looked up,
gettemplater() function isn't useful. Keeping it would introduce another
bug I've made and fixed earlier in this series.
ui.graphnodetemplate config should be a literal template as ui.logtemplate is.
The use of formatter.gettemplater() is valid only for a template string
given by -T/--template option.
I believe it was a mistake to open file in text mode. Now '\r' is preserved
on Windows, but it should be okay to print '\r\n' as long as users live in
such platform.
Prior to this the return value was potentially None, a string, or a
list of strings. It now always returns a list of strings where each
string is always only one email address
Yuya Nishihara gave this suggestion on the mailing list after the
previous patch was queued, and honestly this seems much simpler and
looks more efficient.
This renames the spanset class to _spanset, and moves its __init__ to new
spanset() function. spanset() is now a factory function.
This allows us to construct a spanset without keeping a repo instance.
Inspired by the dirstate fix in 39954a8760cd, this should fix any race
conditions with the fsmonitor state changing from underneath.
Since we now grab the wlock for any non-invalidate writes, the only situation
this appears to happen in is with a concurrent invalidation. Test that.
This means that the state will not be written if:
(1) either the wlock can't be obtained
(2) something else came along and changed the dirstate while we were in the
middle of a status run.
Some extensions like fsmonitor need to run code after dirstate.status is
called, but while the wlock is held. The extensions could grab the wlock again,
but that has its own peculiar race issues. For example, fsmonitor would not
like its state to be written out if the dirstate has changed underneath (see
issue5581 for what can go wrong in that sort of case).
To protect against these sorts of issues, allow extensions to declare that they
would like to run some code to run at fixup time.
fsmonitor will switch to using this in the next patch in the series.
Context manager has a mechanism to control extension propagation. It is not
used by profiling right now, but making the code correct will help prevent bug
in the future.
There are no way for this to happen today, but better be safe than sorry, no
one know how the code will evolve. We now make sure the file pointer is closed
even is profiler is None.
This replaces 'if y in subset' with '& subset'. first(null) and last(wdir())
are fixed thanks to fullreposet.__and__.
This also revealed that first() and last() don't follow the order of the
input set. 'ls & subset' is valid only if the ordering requirement is 'define'
or 'any'.
No performance regression observed:
revset #0: limit(0:9999, 100, 9000)
0) 0.001164
1) 0.001135
revset #2: 9000 & limit(0:9999, 100, 9000)
0) 0.001224
1) 0.001181
revset #3: last(0:9999, 100)
0) 0.000237
1) 0.000199
last() is implemented using a reversed iterator, so the result should be
reversed again.
I've marked this as BC since it's quite old bug seen in 3.0. The first bad
revision is 1ef0875a62f8 "revset: changed last implementation to use lazy
classes."
Instead of walking all ancestors to compute the full set we now check membership
lazily. This massively speed.
On a million-ish revision repository, this remove 14 seconds from the push logic,
making the checkheads function disappear from profile.
The obsolete post-processing needs to know the extend of the pushed set. The
way it is implemented is... suboptimal. It build a full set of all nodes in the
pushset and it does so using changectx. We have much better API for this now.
The simplest is to use the existing lazy ancestors computation. That logic uses
revnum and not node (for good reason) so we start with updating the
post-processing code to handle a "allfuturecommon" set containing revision
numbers.
We are about to call 'torev' on node that might be locally missing. In this
case, 'nodemap.revs' will return None (something valid in our usecase) while
'changelog.rev' would raise an exception.
We make this change in a distinct changeset to show it does not impact the
tests.
We are about to make "allfuturecommon" a set of revs instead of a set of nodes.
The function updated in this patch do not needs to know about these details so
we just pass it a 'ispushed(node)' function. This will simplify the next
changeset.
It seems sufficiently simple to use "profile(enabled=X)" to not justify having
a dedicated context manager just to read the config.
(I do not have a too strong opinion about this).
We now process the "--profile" a second time after alias has been processed and
the command argument fully parsed. If appropriate we enable profiling at that
time.
In these situation, the --profile will cover less than if the full --profile
flag was passed on the command line. This is better than the previous behavior
(flag ignored) and still fullfil multiple valid usecases.
