Performance benchmarking:
$ time hg log -qr "first(desc(hg))"
changeset: 0:3a6a38229d41
real 0m2.210s
user 0m2.158s
sys 0m0.049s
$ time ./hg log -qr "first(desc(hg))"
changeset: 0:3a6a38229d41
real 0m0.171s
user 0m0.131s
sys 0m0.035s
Performance Benchmarking:
$ time hg log -qr "first(date(05/03/2005))"
0:3a6a38229d41
real 0m3.157s
user 0m2.994s
sys 0m0.087s
$ time ./hg log -qr "first(date(05/03/2005))"
0:3a6a38229d41
real 0m0.509s
user 0m0.289s
sys 0m0.070s
Performance benchmarking:
$ time hg log -qr "first(author(mpm))"
0:3a6a38229d41
real 0m3.486s
user 0m3.317s
sys 0m0.077s
$ time ./hg log -qr "first(author(mpm))"
0:3a6a38229d41
real 0m0.551s
user 0m0.295s
sys 0m0.072s
Performance benchmarking:
$ time hg log -qr "first(keyword(changeset))"
0:3a6a38229d41
real 0m3.466s
user 0m3.345s
sys 0m0.072s
$ time ./hg log -qr "first(keyword(changeset))"
0:3a6a38229d41
real 0m0.365s
user 0m0.199s
sys 0m0.083s
Performance benchmarking:
$ time hg log -qr "first(branch(default))"
0:3a6a38229d41
real 0m3.130s
user 0m3.025s
sys 0m0.074s
$ time ./hg log -qr "first(branch(default))"
0:3a6a38229d41
real 0m0.300s
user 0m0.198s
sys 0m0.069s
Performance Benchmarking:
$ time hg log -l1 -qr "branch(default)"
0:3a6a38229d41
real 0m3.366s
user 0m3.217s
sys 0m0.095s
$ time ./hg log -l1 -qr "branch(default)"
0:3a6a38229d41
real 0m0.389s
user 0m0.199s
sys 0m0.061s
Now that every necessary information is held in the `pushoperation` object, we
can finally extract the phase synchronisation phase to it's own function. This
is the first concrete block of code we extract from the huge push function.
Hooray!
This changeset is pure code movement only.
The set of outgoing and common changeset are used by phases to compute the new
common set between local and remote. So we need to move it into the object to
extract the phase sync from the god function.
Note that this information will be used by obsolescence markers too.
The return code convey information about the success of changeset push. This is
used by phases to compute the new common set between local and remote. So we
need to move it into the object to extract the phase sync from the god
function.
Note that this information will be used by obsolescence markers too.
Now that pushop is holding all the push related data, we do not really need a
closure anymore. So we start feeding the object to `localphasemove` and will
make it a normal function in the next commit.
During push, we try to lock the local repo to move local phase according to what
we saw/pushed on the remote repo. Locking the repo may fail, in that case we let
the push proceed without local phase movement (printing warning).
This mean we have code in phase synchronisation that will check if the local repo is
locked or not. we need to move this information in the push object to be able to
extract the phase synchronisation in its own function. This is done as a boolean
because putting reference to the actual lock outside of the main function
sounded a bad idea.
The obsolescence marker exchange code was already extracted during a previous
cycle. We are moving the extracted functio in this module. This function will
read and write data in the `pushoperation` object and I prefer to have all core
function collaborating through this object in the same place.
This changeset is pure code movement only. Code change for direct consumption of
the `pushoperation` object will come later.
This fixes an issue introduced in 818c8992811a where, when disabling
demandimport while running hooks, it's inadvertently re-enabled even when
it was never enabled in the first place.
This doesn't affect normal command line usage of Mercurial; it only matters
when Mercurial is run with demandimport intentionally disabled.
Merge could overwrite untracked files and cause data loss.
Instead we now handle the 'local side removed file and has untracked file
instead' case as the 'other side added file that local has untracked' case:
FILE: untracked file exists
abort: untracked files in working directory differ from files in requested revision
It could perhaps make sense to create .orig files when overwriting, either
instead of aborting or when overwriting anyway because of force ... but for now
we stay consistent with similar cases.
This class allows us to return values from large revsets as soon as they are
computed instead of having to wait for the entire revset to be calculated.
win32.spawndetached starts the detached process by `cmd.exe` (or COMSPEC). The
pid it returned was the one of cmd.exe and not the one of the detached process.
When this pid is used to kill the process, the detached process is not killed,
but only cmd.exe.
With this patch the pid of the detached process is written to the pid file.
Killing the process works as expected.
The pid is only evaluated on writing the pid file. It is unnecessary to search
the pid when it is not needed. And more important, it probably does not yet
exist right after the cmd.exe process was started. When the pid is written to
the file, waiting for the start of the detached process has already happened.
Use this functionality instead of writing a 2nd wait function.
Many tests on windows will not fail anymore, all those with the first failing
line "abort: child process failed to start". (The processes still hanging
around from previous test runs have to be killed first. They still block a
tcp port.)
A good test for the functionality of this patch is test-treediscovery.t,
because it starts and kills `hg serve -d` several times.
msys (on windows) converets '-R bundle:.XX/XX' to '-R bundle:;.XX/XX'. Avoid
this by writing '-R bundle://.XX/XX'. This is used more often than the
alternative work arounds like '-Rbundle://.XX/XX' or '-R bundle:Y/../.XX/XX'.
Subversion issues involving svn log such as 1e493b49245f can be tricky to
debug when it is run in an 'hg debugsvnlog' sub process. Debugging is simpler
when convert only uses one process.
With this change convert will invoke the svn log directly when setting
[convert]
svn.debugsvnlog = False
This is intentionally not documented.
It was hard for the user to know what was going on when unshelving - especially
if the user had to resolve conflicts and thus got to see the intermediate
states.
Seeing that pending changes was gone could scare the user, make him panic, and
do stuff that really made him lose data.
Merging (both when rebasing and with pending changes) also requires some
understanding of where in the process you are and what you are merging.
To help the user we now show a couple of status messages (when relevant):
temporarily committing pending changes (restore with 'hg unshelve --abort')
rebasing shelved changes
unshelve was quite verbose and it was hard for a user to follow what really was
going on. It ended up saying 'added 1 changesets' ... but the user just
expected and got pending changes and never saw any changeset.
The use of bundles is an implementation detail that we don't have to leak here.
Pulling is quite verbose, optimized for pulling many changesets from remote
repos - that is not the case here.
Instead, set the quiet flag when pulling the bundle - not only when temporarily
committing pending changes.
The 'finally' restore of ui.quiet is moved to the outer try/finally used for
locking.
The shelved changes _could_ perhaps be amended to the parent changeset but it
_is_ not the parent changeset. Using the description from the parent changeset
is thus wrong and confusing.
Instead, add a 'changes to' prefix.
Shelve do normally take a list of files or patterns to shelve and the command
summary should thus show [FILE]...
Note: --delete is a bit special and interpret the parameters as a list of
shelve names. This change makes that even less obvious from the help. Too bad
- we can't please everyone.
publicancestors returned the parents of the public ancestors ... and
changegroupsubset used the parents of these as base for the bundle. That gave
bundles with one layer of changesets more than necessary.
changegroupsubset will take the parents of the roots to find the bases.
Other parts of Mercurial do not expect that, and a result of that is that some
bundles contain more changesets than necessary.
No real changes here - just renaming a parameter to document what it is.
A correct patch for this has existed in Python's BTS for 3 years
(http://bugs.python.org/issue9291), so waiting for it to be fixed
upstream is probably not a viable strategy. Instead, we add this
horrible hack to workaround the issue in existing copies of Python
2.4-2.7.
