FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 05 Nov 2014 23:24:47 +0900] rev 23183
largefiles: remove meaningless code path for "hg pull --rebase"
This patch removes "--rebase" specific code path for "hg pull" in
"overridepull", because previous patch makes it meaningless: now,
"rebase.rebase" ("orig" invocation in this patch) can
update/commit largefiles safely without "repo._isrebasing = True".
As a side effect of removing "rebase.rebase" invocation in
"overridepull", this patch removes "nothing to rebase ..." message in
"test-largefiles.t", which is shown only when rebase extension is
enabled AFTER largefiles:
before this patch:
1. "dispatch" invokes "pullrebase" of rebase as "hg pull" at
first, because rebase wraps "hg pull" later
2. "pullrebase" invokes "overridepull" of largefiles as "orig",
even though rebase assumes that "orig" is "pull" of commands
3. "overridepull" executes "pull" and "rebase" directly
3.1 "pull" pulls changesets and creates new head "X"
3.2 "rebase" rebases current working parent "Y" on "X"
4. "overridepull" returns to "pullrebase"
5. "pullrebase" tries to rebase, but there is nothing to be done,
because "Y" is already rebased on "X". then, it shows "nothing
to rebase ..."
after this patch:
1. "dispatch" invokes "pullrebase" of rebase as "hg pull"
2. "pullrebase" invokes "overridepull" of largefiles as "orig"
3. "overridepull" executes "pull" as "orig"
4. "overridepull" returns to "pullrebase"
5. revision "Y" is not yet rebased, so "pullrebase" doesn't shows
"nothing to rebase ..."
As another side effect of removing "rebase.rebase" invocation, this
patch fixes issue3861, which occurs only when rebase extension is
enabled BEFORE largefiles:
before this patch:
1. "dispatch" invokes "overridepull" of largefiles at first,
because largefiles wrap "hg pull" later
2. "overridepull" executes "pull" and "rebase" explicitly
2.1 "pull" pulls changesets and creates new head "X"
2.2 "rebase" rebases current working parent, but fails because
no revision is checked out in issue3861 case
3. "overridepull" returns to "dispatch" with exit code 1 returned
from "rebase" at (2.2)
4. "hg pull" terminates with exit code 1 unexpectedly
after this patch:
1. "dispatch" invokes "overridepull" of largefiles at first
2. "overridepull" invokes "pullrebase" of rebase as "orig"
3. "pullrebase" invokes "pull" as "orig"
4. "pullrebase" invokes "rebase", and it fails
5. "pullrebase" returns to "overridepull" with exit code 0
(because "pullrebase" ignores result of "pull" and "rebase")
6. "overridepull" returns to "dispatch" with exit code 0 returned
from "rebase" at (5)
7. "hg pull" terminates with exit code 0
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 05 Nov 2014 23:24:47 +0900] rev 23182
largefiles: wrap "rebase.rebase" for functions using it directly
Before this patch, largefiles extension wraps only "rebase" in the
command table by "extensions.wrapcommand". But there are some
functions using "rebase.rebase" directly.
Without special care for them, largefiles extension can't work
correctly with such functions. In addition to it, "special care" often
becomes complicated and awkward. For example:
- "unshelve" can't get correct result of "rebase.rebase", because of
lack of special care
- special care for "hg pull --rebase" causes issue3861
This patch wraps "rebase.rebase" for functions using it directly.
For simplicity, this patch keeps 'special care for "hg pull --rebase"'.
It is removed in the subsequent patch.
Sune Foldager <cryo@cyanite.org> [Fri, 17 Oct 2014 14:41:11 +0200] rev 23181
changegroup: introduce cg2packer/unpacker
cg2 supports generaldelta in changegroups, to be used in bundle2.
Since generaldelta is handled directly in cg2, reordering is switched
off by default.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 12:19:24 -0700] rev 23180
push: send highest changegroup format supported by both side
When using bundle2, we find the common subset of supported changegroup-packers
and we pick the max of them. This allow to use generaldelta aware changegroups through
bundle2.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 14:59:10 +0200] rev 23179
getbundle: send highest changegroup format supported by both side
When using bundle2, we find the common subset of supported changegroup-packers
and we pick the max of them. This allow to use generaldelta aware changegroup
through bundle2.
Sune Foldager <cryo@cyanite.org> [Fri, 17 Oct 2014 14:41:21 +0200] rev 23178
changegroup: allow use of different cg#packer in getchangegroupraw
This will allow the use of general delta aware changegroup formats.
Sune Foldager <cryo@cyanite.org> [Fri, 17 Oct 2014 14:41:02 +0200] rev 23177
changegroup: introduce "raw" versions of some commands
The commands getchangegroup, getlocalchangegroup and getsubset now each
have a version ending in -raw. The raw versions return the chunk generator
from the changegroup packer directly, without wrapping it in a chunkbuffer
and unpacker. This avoids extra chunkbuffers in the bundle2 code path.
Also, the raw versions can be extended to support alternative packers
in the future, to be used from bundle2.
Matt Mackall <mpm@selenic.com> [Tue, 04 Nov 2014 16:43:33 -0600] rev 23176
merge with stable
Pascal Quantin <pascal.quantin@gmail.com> [Tue, 04 Nov 2014 21:54:27 +0100] rev 23175
win32: remove Mercurial.ini file from Inno Setup installer (issue4435)
Pascal Quantin <pascal.quantin@gmail.com> [Tue, 04 Nov 2014 21:35:49 +0100] rev 23174
win32: fix win32 installers generation
cd0c51c07e5f introduced a typo preventing a proper generation of the
installers. Also remove ConcatenateFiles() function as it is no more
required.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 04 Nov 2014 13:38:33 +0000] rev 23173
patchbomb: add label and color to the confirm output
The current output is mostly a wall of text. This makes it hard to
actually check something for people with lazy eyes. We use labels and
colors to make it more joyful (and get the patch summaries to stand
out). The colors have been arbitrarily choosen. They can be changed
later if someone has a more scientific choice.
Yuya Nishihara <yuya@tcha.org> [Tue, 04 Nov 2014 23:41:46 +0900] rev 23172
tests: write hgrc of more than two lines by using shell heredoc
Here document should be readable than repeating echo commands.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 04 Nov 2014 10:40:06 +0000] rev 23171
perf: use a formatter for output
We use a `formatter` object in the perf extensions. This allow the use of
formatted output like json. To avoid adding logic to create a formatter and pass
it around to the timer function in every command, we add a `gettimer` function
in charge of returning a `timer` function as simple as before but embedding an
appropriate formatter.
This new `gettimer` function also return the formatter as it needs to be
explicitly closed at the end of the command.
example output:
$ hg --config ui.formatjson=True perfvolatilesets visible obsolete
[
{
"comb": 0.02,
"count": 126,
"sys": 0.0,
"title": "obsolete",
"user": 0.02,
"wall": 0.0199398994446
},
{
"comb": 0.02,
"count": 117,
"sys": 0.0,
"title": "visible",
"user": 0.02,
"wall": 0.0250301361084
}
]
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 24 Sep 2014 21:33:12 -0700] rev 23170
bundle2: support a "version" argument in `changegroup` part
When included, this mandatory parameter (mandatory == cannot be ignored) lets the
part handler select the right cgunpacker class.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 24 Sep 2014 21:28:54 -0700] rev 23169
bundle2caps: advertise the available versions for changegroup packer
This will let the bundle2 client and server detect what packer they should be using.
This detection part is not done. I expect it to be done with the addition of the
second packer (with generaldelta support).
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 24 Sep 2014 21:24:06 -0700] rev 23168
changegroup: add a "packermap" dictionary to track different packer versions
We only have "01" right now, but we should get general delta in soon.
Bundle2 is expected to make use of this to advertise and select the right packer
to use on both sides.