Let us start registering the existing option. I'm starting with the 'devel'
section because it is full of useful things that are poorly documented. So
registering these will more than other section.
We were passing it as a revision number in one place and as a context
in another. It worked because the only use was in "repo[dest].rev()",
but it was confusing. By always passing a revision number, we can also
remove that unnecessary lookup.
The function lost its last caller in ae209b610844 (patch: replace
functions in fsbackend to use vfs, 2014-06-05) when the callers
started relying on the opener to do the join.
patchbackend() seems to call it on an arbitrary backend, so it seems
to be part of the API. Since all subclasses do something in their
close() methods, I decided to let this one raise an exception rather
than just pass.
Extensions sometimes wants to add other information in the default log output
format (when no templating is used).
Add an empty function named '_exthook' for easing the extension life.
Extensions will be able to wrap this function and collaborate to display
additional information.
Exthook is called after displaying troubles and just before displaying the
files, extra and description.
Add a new test file to test it and not pollute other test files.
This patch adds special comment handling so one can create obsmarkers in
drawdag comments like "# replace: A -> B -> C", "# prune: X, Y, Z",
"split: P -> M, N" and they are just self-explained.
One hitch is that sometimes fcd is actually an absentfilectx which does not
expose any mutator functions. In order to still use the context functions,
we look up the underlying workingfilectx to perform the write there.
One alternate way would be to put the write functions on the absentfilectx and
have them pass-through. While this makes the callsites cleaner, we would need
to decide what its getter functions would return after this point, since
returning None for `data` (and True for `isabsent()`) might no longer be
correct after a write. I discussed with Sidd about just having the getters
raise RuntimeErrors after a mutator has been called, but we actually call
isabsent() in merge.py after running the internal merge tools.
Yuya pointed out that using mutable value as the default could be problematic.
To work around this we now support callable object as default value. This
allows for creating new mutable objects on demand when needed.
None of this function has been used in the past 5 years, so I think it is safe
to just kill them. All code accessing rich markers is using 'getmarkers(...)'
instead (or raw markers).
Update the code to correctly anchor the expression on the end of the name, to
require that the entire name match this expression. It was already anchored at
the start by using re.match(), but this does not anchor it at the end.
The 4.2 release introduces a regression regarding the behavior of rebase with
some hook failures. We add the tests from the bug report from Henrik Stuart to
our test base to prevent further regression on this.
Having a single transaction for rebase means the whole transaction gets rolled back
on error. To work around this a small hack has been added to detect merge
conflict and commit the work done so far before exiting. This hack works because
there is nothing transaction related going on during the merge phase.
However, if a hook blocks the rebase to create a changeset, it is too late to commit the
work done in the transaction before the problematic changeset was created. This
leads to the whole rebase so far being rolled back. Losing merge resolution and
other work in the process. (note: rebase state will be fully lost too).
Since issue5610 is a pretty serious regression and the next stable release is a
couple day away, we are taking the backout route until we can figure out
something better to do.
In the process of fixing issue5610 in 4.2.2, we are trying to backout
507f16f4aa51. This changeset is making changes that depend on 507f16f4aa51,
so we need to back it out first.
Since issue5610 is pretty serious regression and the next stable release is a
couple of days away, we are taking the backout route until we can figure out
something better to do.
As part of using `hg show` in my daily workflow, I've found it slightly
annoying to have to type full view names, complete with a space. I've
locally registered an alias for "swork = show work."
I think others will have this same complaint and could benefit from
some automation to streamline the creation of aliases. So, this
commit introduces a config option that allows `hg show` views to be
automatically aliased using a given prefix. e.g. a value of "s"
will automatically register "swork" and "sbookmarks." Multiple
values can be given for ultimate flexibility. This arguably isn't
needed now. But since we don't register aliases if there will be
a collision and we're bound to have a collision, it makes sense to
allow multiple prefixes so specific views can avoid collisions by
using different prefixes.
Since its introduction in c7ec460797a9, the parameter has always been name
"error". Yet the eol extension have been using 'haserror' as the argument name,
breaking extensions with subclass passing 'error' as a keyword argument.
Now that the default value is also converted we can use a human readable version
for it. This will be useful if we start to automatically display the default
config value in various place.
Extensions can have a 'configtable' mapping and use
'registrar.configitem(table)' to retrieve the registration function.
This behave in the same way as the other way for extensions to register new
items (commands, colors, etc).
We simplify the unstable computation code, skipping the expensive creation of
changectx object. We focus on efficient set operation and revnumber centric
functions.
In my mercurial development repository, this provides a 3x speedup to the
function:
before: 5.319 ms
after: 1.844 ms
repo details:
total changesets: 40886
obsolete changesets: 7756
mutable (not obsolete): 293
unstable: 30
Update the syshgenv function to attempt to completely restore the original
environment, rather than only updating a few specific variables. run_tests.py
now generates a shell script that can be used to restore the original
environment, and syshgenv sources it.
This is a bit more complicated than the previous code, but should do a better
job of running the system hg in the correct environment.
I've tested it on Linux using python 2.x, but let me know if it causes issues
in other environments. I'm not terribly familiar with how the tests get run on
Windows, for instance, and how the environment needs to be updated there.
Ancient hg does not have "hg files" so test-check-*.t will fail with
"unknown command 'files'":
$ hg files
hg: unknown command 'files'
$ hg --version
Mercurial Distributed SCM (version 2.6.2)
Test "hg files" and give up using syshg if it does not have "files" command.