Tue, 06 Oct 2015 02:05:56 -0700 extract: directly assign parent to data dictionary
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:05:56 -0700] rev 26550
extract: directly assign parent to data dictionary The temporary variables are not adding anything.
Tue, 06 Oct 2015 02:04:46 -0700 extract: assign message only once
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:04:46 -0700] rev 26549
extract: assign message only once This return is shared between the two cases. We can move it earlier.
Tue, 06 Oct 2015 02:04:06 -0700 extract: simplify parents assignement
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:04:06 -0700] rev 26548
extract: simplify parents assignement We move to the more standard style of: value = default if special: value = other This is more consistent and compact.
Tue, 06 Oct 2015 02:01:53 -0700 patch: move 'extract' return to a dictionnary
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:01:53 -0700] rev 26547
patch: move 'extract' return to a dictionnary The final goal here is to be able to parse, return and process arbitrary data from patch. This mirror the recently added ability to add arbitrary data to patch headers. The first step is to return something more flexible, so we return a dict without changing any other logic.
Tue, 06 Oct 2015 01:49:04 -0700 patchbomb: add experimental config of a "pullurl" and export it
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 01:49:04 -0700] rev 26546
patchbomb: add experimental config of a "pullurl" and export it This config allows to specify a public location where your changeset can be found. It then include a dedicated patch header show a command to be used to retrieve the change. See the test for example. This is flagged as experimental because this feature is not safe until we have more logic to test that: - changeset actually exists on destination - changeset is draft on destination. As all this is experimental, bike shedding can happily happens before we remove the experimental flag.
Mon, 05 Oct 2015 23:17:01 -0700 export: introduce a generic way to add patch header on export
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 23:17:01 -0700] rev 26545
export: introduce a generic way to add patch header on export Extensions currently have no easy way to add data to exported patch. This is now fixed using a generic mechanism in the same fashion used by bundle2. Tests are coming in the next changeset with its first user.
Mon, 05 Oct 2015 00:23:20 -0700 incoming: request a bundle2 when possible (BC)
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 00:23:20 -0700] rev 26544
incoming: request a bundle2 when possible (BC) Incoming was using bundle1 in all cases, as bundle1 is restricted to changegroup1 and does not support general delta, this can lead to significant CPU overhead if the server is using general delta storage. We now properly request and store a bundle2 to disk. If the server include any output or error in the bundle, they will be stored on disk and replayed when the bundle is read. As 'hg incoming' is going to read the bundle right away, we call that 'good' enough and go back to the bigger plan of having general delta on by default. This was tracked as 4864
Mon, 05 Oct 2015 00:18:11 -0700 bundlerepo: indent some code to prepare next patch
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 00:18:11 -0700] rev 26543
bundlerepo: indent some code to prepare next patch We are about to add a new condition. Code is indented in a separated patch for readability.
Thu, 08 Oct 2015 01:40:21 -0700 bundle2: add a way to just forward the bundle2 stream to another user
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 08 Oct 2015 01:40:21 -0700] rev 26542
bundle2: add a way to just forward the bundle2 stream to another user There is use case for directly forward and bundle2 stream from the peer to a file (eg: 'hg incoming --bundle'), However ssh peers have no way to know the 'getbundle' is over except for actually interpreting the bundle. So we need to have the unbundle do the interpreting and forward job. The function is marked as private to highlight that this is terrible and that we are sorry.
Mon, 05 Oct 2015 01:10:49 -0700 bundle2: split parameter retrieval and processing
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 01:10:49 -0700] rev 26541
bundle2: split parameter retrieval and processing We want to introduce a simple way to forward the content of a bundle2 stream. For this purpose, we will need to both yield the parameters block and process it (to apply any behavior change it might indicate).
Mon, 05 Oct 2015 00:14:47 -0700 changegroup: extract the file management part in its own function
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 00:14:47 -0700] rev 26540
changegroup: extract the file management part in its own function The current writebundle function do two things: - taking a changegroup-packer instance and storing it into a valid bundle with proper header. - creating a temporary or requested file to store that bundle We would like to make it easier to forward bundle stream directly from a remote peer to a file, so we split the two logic to be able to skip the one about building a valid bundle (the remote is already sending one).
Sun, 04 Oct 2015 21:48:19 -0700 unbundle: properly read head modification result from bundle2
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 04 Oct 2015 21:48:19 -0700] rev 26539
unbundle: properly read head modification result from bundle2 We were reading the wrong key...
Wed, 07 Oct 2015 23:04:31 +0900 revset: strip off "literal:" prefix from bookmark not found error
Yuya Nishihara <yuya@tcha.org> [Wed, 07 Oct 2015 23:04:31 +0900] rev 26538
revset: strip off "literal:" prefix from bookmark not found error This is what branch() and tag() do.
Wed, 07 Oct 2015 23:00:29 +0900 revset: do not fall through to revspec for literal: branch (issue4838)
Yuya Nishihara <yuya@tcha.org> [Wed, 07 Oct 2015 23:00:29 +0900] rev 26537
revset: do not fall through to revspec for literal: branch (issue4838) If "literal:" is specified, it must not be a revset expression. It should error out with a better message.
Wed, 07 Oct 2015 21:08:14 +0100 hgweb: ensure both foreground and background colors are specified (issue4872)
Gijs Kruitbosch <gijskruitbosch@gmail.com> [Wed, 07 Oct 2015 21:08:14 +0100] rev 26536
hgweb: ensure both foreground and background colors are specified (issue4872) When users configure the default foreground or background color to non-default (black on white) values, several hgweb styles lack contrast for headers and table row items. This patch fixes that by ensuring that where either foreground or background colors are specified, both are specified.
Thu, 08 Oct 2015 23:24:38 +0900 templater: do not pre-evaluate generator keyword at runsymbol (issue4868) stable
Yuya Nishihara <yuya@tcha.org> [Thu, 08 Oct 2015 23:24:38 +0900] rev 26535
templater: do not pre-evaluate generator keyword at runsymbol (issue4868) It was introduced by e06e9fd2d99f, but the important code was removed by a3c2d9211294. So there was no positive effect other than exhausting memory. The problem spotted by e06e9fd2d99f is that you can't use a generator keyword more than once. For example, in hgweb template, "{child} {child}" doesn't work because the first "{child}" consumes the generator. But as a3c2d9211294 says, the fix was wrong because it could overwrite a callable keyword that returns a generator. Also the fix didn't work for a generator of generator such as "{diff}" keyword. So, the proper fix for that problem would be to not put a generator in a keyword table. Instead, it should be a factory of a generator. Note that this should fix the memory issue in hgweb, but my firefox killed by OOM in place. Be careful to not use a modern web browser to test the issue4868.
Mon, 05 Oct 2015 01:47:33 -0700 merge: drop special parent assignment in the obsolete case
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 01:47:33 -0700] rev 26534
merge: drop special parent assignment in the obsolete case We can safely drop this because the very same assignment is enforcement later in the function. Dropping it will make it simpler to extract the default destination logic in its own function.
Thu, 01 Oct 2015 20:31:43 -0700 bundle: use bundle2 if repository uses general delta
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 20:31:43 -0700] rev 26533
bundle: use bundle2 if repository uses general delta As bundle1 does not support generaldelta, this would mean recomputing delta at bundle time. This is similar to what we do for strip and shelve and was tracked as issue4865.
Thu, 01 Oct 2015 20:21:16 -0700 parsebundletype: add a comment for future generation
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 20:21:16 -0700] rev 26532
parsebundletype: add a comment for future generation
Thu, 01 Oct 2015 19:16:00 -0700 bundle: extend the format of --type to support version and compression
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 19:16:00 -0700] rev 26531
bundle: extend the format of --type to support version and compression We had some basic undocumented support for uncompressed bundle2 support. We now have an official extensible syntax to specify both format type and compression (eg: bzip2-v2). In practice, this changeset introduce the 'v1' and 'v2' identifier to make it possible to combine format and compression. The default format is still 'v1'. We'll care about picking 'v1' or 'v2' in regard with general delta in the next changesets.
Wed, 07 Oct 2015 20:19:20 +0100 hgweb: fix border-radius for standards-based browsers
Gijs Kruitbosch <gijskruitbosch@gmail.com> [Wed, 07 Oct 2015 20:19:20 +0100] rev 26530
hgweb: fix border-radius for standards-based browsers While here, remove an old gecko-specific property, as gecko has supported the unprefixed version for many years.
Wed, 07 Oct 2015 21:28:43 -0700 filemerge: move precheck to before files are written out
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 21:28:43 -0700] rev 26529
filemerge: move precheck to before files are written out This is much simpler, and also avoids unnecessary disk IO.
Wed, 07 Oct 2015 22:58:52 -0700 filemerge: move 'merging' output to before file creation
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 22:58:52 -0700] rev 26528
filemerge: move 'merging' output to before file creation This has no visible impact but makes some future work simpler.
Wed, 07 Oct 2015 21:21:56 -0700 filemerge.filemerge: make a tuple containing merge paths on disk
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 21:21:56 -0700] rev 26527
filemerge.filemerge: make a tuple containing merge paths on disk We're going to need this same tuple elsewhere.
Wed, 07 Oct 2015 16:14:57 -0700 filemerge: switch trymerge boolean to mergetype enum
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 16:14:57 -0700] rev 26526
filemerge: switch trymerge boolean to mergetype enum trymerge = False becomes mergetype = nomerge, and trymerge = True becomes mergetype = fullmerge or mergeonly, depending on whether a premerge happens.
Wed, 07 Oct 2015 15:13:41 -0700 filemerge: add some merge types
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 15:13:41 -0700] rev 26525
filemerge: add some merge types We're going to turn the 'trymerge' boolean into a 'mergetype' enum with these three possible values.
Thu, 08 Oct 2015 01:41:30 +0900 shelve: restore unshelved dirstate explicitly after aborting transaction
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 08 Oct 2015 01:41:30 +0900] rev 26524
shelve: restore unshelved dirstate explicitly after aborting transaction Before this patch, "hg unshelve" uses aborting a current transaction to discard temporary changes while unshelving. This assumes that dirstate changes in a transaction scope are kept even after aborting it. But this assumption will be broken by "transactional dirstate". See the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan This patch explicitly saves shelved dirstate just before aborting current transaction, and restore dirstate with it after aborting by utility function '_aborttransaction()' added by previous patch.
Thu, 08 Oct 2015 01:41:30 +0900 shelve: restore shelved dirstate explicitly after aborting transaction
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 08 Oct 2015 01:41:30 +0900] rev 26523
shelve: restore shelved dirstate explicitly after aborting transaction Before this patch, "hg shelve" uses aborting a current transaction to discard temporary changes while shelving. This assumes that dirstate changes in a transaction scope are kept even after aborting it. But this assumption will be broken by "transactional dirstate". See the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan This patch explicitly saves shelved dirstate just before aborting current transaction, and restore dirstate with it after aborting by utility function '_aborttransaction()' added by previous patch. This patch replaces 'if tr: tr.abort()' by 'lockmod.release(tr)', because the former is already done in '_aborttransaction()' (and the latter has no effect), if current transaction is aborted in it successfully. Otherwise, the latter is enough to trigger aborting.
Thu, 08 Oct 2015 01:41:30 +0900 shelve: add utility to abort current transaction but keep dirstate
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 08 Oct 2015 01:41:30 +0900] rev 26522
shelve: add utility to abort current transaction but keep dirstate "hg shelve" and "hg unshelve" use aborting a current transaction to discard temporary changes while (un)shelving. This assumes that dirstate changes in a transaction scope are kept even after aborting it. But this assumption will be broken by "transactional dirstate". See the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan This patch adds utility function "_aborttransaction()" to abort current transaction but keep dirstate changes for (un)shelving. 'dirstate.invalidate()' just after aborting a transaction should be removed soon by subsequent patch, which writes or discards in-memory dirstate changes at releasing transaction according to the result of it. BTW, there are some other ways below, which (seem to, at first glance) resolve this issue. But this patch chose straightforward way for ease of review and future refactorring. - commit transaction at first, and then rollback it It causes unintentional "dirty read" of running transaction to other processes at committing it. - use dirstateguard to save and restore shelved dirstate After DirstateTransactionPlan, making 'dirstate.write()' write in-memory changes into actual file requires 'transaction.writepending()' while transaction running. It causes meaningless writing other in-memory changes out, even though they are never referred. In addition to it, it isn't desirable that scope of dirstateguard and transaction intersects each other. - get list of files changed from the parent, keep it in memory, and emulate that changes after aborting transaction This additional memory consumption may block aborting transaction in large repository (on small resource environment).
Thu, 08 Oct 2015 01:41:30 +0900 dirstate: split write to write changes into files other than .hg/dirstate
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 08 Oct 2015 01:41:30 +0900] rev 26521
dirstate: split write to write changes into files other than .hg/dirstate '_writedirstate()' is used mainly for "transactional dirstate". See the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip