Fri, 09 Oct 2015 15:37:05 -0700 discovery: fix a typo in a comment
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 15:37:05 -0700] rev 26596
discovery: fix a typo in a comment The idea here is that the code is imperfect, not that it is impossible to get something behaving properly.
Fri, 09 Oct 2015 14:59:37 -0700 getsubset: get the unpacker version from the bundler
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 14:59:37 -0700] rev 26595
getsubset: get the unpacker version from the bundler The current setup requires to pass both a packer and, optionally, the version of the unpacker. This is confusing and error prone as the two value cannot mismatch. Instead, we simply grab the version from the packer. This fixes a bug where requesting a cg2 from 'hg bundle' were reported as changegroup 1. I should have caught that in the initial changeset but I missed it somehow.
Mon, 12 Oct 2015 15:42:32 +0300 test-convert-cvs: add sleep so cvs notices changes
Emanuele Giaquinta <emanuele.giaquinta@gmail.com> [Mon, 12 Oct 2015 15:42:32 +0300] rev 26594
test-convert-cvs: add sleep so cvs notices changes This change makes the test pass on gcc112.fsffrance.org.
Wed, 07 Oct 2015 11:33:52 +0300 cvsps: fix computation of parent revisions when log caching is on
Emanuele Giaquinta <emanuele.giaquinta@gmail.com> [Wed, 07 Oct 2015 11:33:52 +0300] rev 26593
cvsps: fix computation of parent revisions when log caching is on cvsps computes the parent revisions of log entries by walking the cvs log sorted by (rcs, revision) and by iteratively maintaining a 'versions' dictionary which maps a (rcs, branch) pair onto the last revision seen for that pair. When log caching is on and a log cache exists, cvsps fails to set the parent revisions of new log entries because it does not iterate over the log cache in the parents computation. A complication is that a file rcs can change (move to/from the attic), with respect to its value in the log cache, if the file is removed/added back. This patch adds an iteration over the log cache to update the rcs of cached log entries, if changed, and to properly populate the 'versions' dictionary.
Tue, 06 Oct 2015 16:26:20 -0500 dirstate: batch calls to statfiles (issue4878)
Matt Mackall <mpm@selenic.com> [Tue, 06 Oct 2015 16:26:20 -0500] rev 26592
dirstate: batch calls to statfiles (issue4878) This makes it more interruptible.
Sun, 11 Oct 2015 18:30:47 +0900 parsers: fix infinite loop or out-of-bound read in fm1readmarkers (issue4888)
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Oct 2015 18:30:47 +0900] rev 26591
parsers: fix infinite loop or out-of-bound read in fm1readmarkers (issue4888) The issue4888 was caused by 0-length obsolete marker. If msize is zero, fm1readmarkers() never ends. This patch adds several bound checks to fm1readmarker(). Therefore, 0-length and invalid-size marker should be rejected.
Sun, 11 Oct 2015 18:41:41 +0900 parsers: read sizes of metadata pair of obsolete marker at once
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Oct 2015 18:41:41 +0900] rev 26590
parsers: read sizes of metadata pair of obsolete marker at once This will make it easy to implement bound checking. Currently fm1readmarker() has no protection for corrupted obsstore and can cause infinite loop or out-of-bound reads.
Wed, 07 Oct 2015 21:51:24 -0700 filemerge: clean up temp files in a finally block
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 21:51:24 -0700] rev 26589
filemerge: clean up temp files in a finally block This isn't really a big deal because the temp files are created in $TMPDIR, but it makes some upcoming work simpler.
Thu, 08 Oct 2015 12:53:09 -0700 check-code: detect and ban 'util.Abort'
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 08 Oct 2015 12:53:09 -0700] rev 26588
check-code: detect and ban 'util.Abort' We have seen the light, please use the new way.
Thu, 08 Oct 2015 12:55:45 -0700 error: get Abort from 'error' instead of 'util'
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 08 Oct 2015 12:55:45 -0700] rev 26587
error: get Abort from 'error' instead of 'util' The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be confused about that and gives all the credit to 'util' instead of the hardworking 'error'. In a spirit of equity, we break the cycle of injustice and give back to 'error' the respect it deserves. And screw that 'util' poser. For great justice.
Mon, 05 Oct 2015 22:49:24 -0700 eol: rename 'error' to 'haserror'
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 22:49:24 -0700] rev 26586
eol: rename 'error' to 'haserror' The variable 'error' conflict with the module name that we would like to import and use in a coming changeset.
Mon, 05 Oct 2015 22:29:57 -0700 discovery: rename 'error' to 'errormsg'
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 22:29:57 -0700] rev 26585
discovery: rename 'error' to 'errormsg' The variable 'error' conflict with the module name that we would like to import and use in a coming changeset.
Mon, 05 Oct 2015 16:44:45 -0700 histedit: delete histedit statefile on any exception during abort
Christian Delahousse <cdelahousse@fb.com> [Mon, 05 Oct 2015 16:44:45 -0700] rev 26584
histedit: delete histedit statefile on any exception during abort When an user aborts a histedit, many things could go wrong. At a minimum, after a histedit abort failure, their repository should be out of that state. We've found situations where the user could not exit the histedit state without manually deleting the histedit state file. This patch ensures that if any exception happens during an abort, the histedit statefile will be deleted so that users are out of the histedit state and can at least manually get the repo back to a workable condition.
Tue, 06 Oct 2015 15:09:28 -0700 histedit: check presence of statefile before deleting it
Christian Delahousse <cdelahousse@fb.com> [Tue, 06 Oct 2015 15:09:28 -0700] rev 26583
histedit: check presence of statefile before deleting it When the histeditstate class instance has it's clear() method called, there is nothing to check to see if the state file exists before deleting it. It may not exist, which would create an exception. This patch allows clear to be called at any time. This will be needed for the following patch.
Mon, 05 Oct 2015 16:34:17 -0700 histedit: add inprogress method to state class
Christian Delahousse <cdelahousse@fb.com> [Mon, 05 Oct 2015 16:34:17 -0700] rev 26582
histedit: add inprogress method to state class If a histedit is progress, the 'histedit-state' file should exist. The patch implements a convenience function to do check if a histedit is in progress. This method will be use in next patch in the series.
Fri, 09 Oct 2015 03:53:47 +0900 commands: use dirstateguard instead of begin/end-parentchange for backout
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:47 +0900] rev 26581
commands: use dirstateguard instead of begin/end-parentchange for backout Before this patch, "hg backout" uses 'begin'/'end'-'parentchange()' of 'dirstate' class to avoid writing incomplete dirstate changes out at failure. But this framework doesn't work as expected, if 'dirstate.write()' is invoked between them. In fact, in-memory dirstate changes may be written out at 'repo.status()' implied by 'merge.update()', even before this patch. To restore dirstate as expected at failure of "hg backout", this patch uses 'dirstateguard' instead of 'begin'/'end'-'parentchange()'.
Fri, 09 Oct 2015 03:53:47 +0900 commands: make "hg import" use dirstateguard only for --no-commit
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:47 +0900] rev 26580
commands: make "hg import" use dirstateguard only for --no-commit Previous patch made dirstate changes in a transaction scope "all or nothing". Therefore, 'dirstateguard' is meaningless, if its scope is as same as one of the related transaction. Before this patch, "hg import" uses 'dirstateguard' always, but transaction is also started if '--no-commit' isn't specified. To avoid redundancy, this patch makes "hg import" use dirstateguard only if transaction isn't started (= '--no-commit' is specified). In this patch, 'if dsguard' can be examined safely, because 'dsguard' is initialized (with None) before outermost 'try'.
Fri, 09 Oct 2015 03:53:46 +0900 cmdutil: stop tryimportone from using dirstateguard (BC)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:46 +0900] rev 26579
cmdutil: stop tryimportone from using dirstateguard (BC) There is no user of 'cmdutil.tryimportone()' other than 'commands.import_()', which can restore dirstate at failure of applying patches by transaction or dirstateguard. Therefore, it is reasonable to stop 'tryimportone()' from using redundant 'dirstateguard', even though it changes behavior of 'tryimportone()'. After this patch, 3rd party extensions should use 'dirstateguard' or so explicitly, if they want to restore dirstate at failure of importing a patch.
Fri, 09 Oct 2015 03:53:46 +0900 dirstate: remove meaningless dirstateguard
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:46 +0900] rev 26578
dirstate: remove meaningless dirstateguard Previous patch made dirstate changes in a transaction scope "all or nothing". Therefore, 'dirstateguard' is meaningless, if its scope is as same as one of the related transaction. This patch removes such meaningless 'dirstateguard' usage.
Fri, 09 Oct 2015 03:53:46 +0900 localrepo: execute appropriate actions for dirstate at releasing transaction
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:46 +0900] rev 26577
localrepo: execute appropriate actions for dirstate at releasing transaction Before this patch, in-memory dirstate changes are still kept over a transaction scope boundary regardless of the result of it. For "all or nothing" policy of the transaction, in-memory dirstate changes should be: - written out at successful closing a transaction, because subsequent 'dirstate.invalidate()' can lose them - discarded at failure of a transaction, because outer 'wlock.release()' or so may write them out To discard all changes in a transaction completely, this patch also restores '.hg/dirstate' by '.hg/journal.dirstate' at failure, because 'transaction' itself does nothing for files related to '.hg/journal.*' in such case (therefore, renaming in this patch is safe enough). This is a part of preparations for "transactional dirstate". See also the wiki page below for detail about it. https://mercurial.selenic.com/wiki/DirstateTransactionPlan This patch also removes redundant 'dirstate.invalidate()' just before aborting a transaction for shelve/unshelve.
Fri, 09 Oct 2015 03:53:46 +0900 transaction: add releasefn to notify the end of a transaction scope
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Oct 2015 03:53:46 +0900] rev 26576
transaction: add releasefn to notify the end of a transaction scope 'releasefn' is used by subsequent patch, to do appropriate action according to the result of it at the end of a transaction scope. To ensure that 'releasefn' is invoked only once, this patch invokes it after assignment 'self.journal = None', because such assignment prevents from invoked 'transaction._abort()' again via '__del__()'. def __del__(self): if self.journal: self._abort()
Wed, 07 Oct 2015 23:35:30 -0700 filemerge: move post-merge checks into a separate function
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 23:35:30 -0700] rev 26575
filemerge: move post-merge checks into a separate function This makes the overall filemerge function easier to follow, and makes upcoming work simpler.
Thu, 08 Oct 2015 14:18:43 -0700 filemerge._xmerge: drop no longer necessary 'if r:' check
Siddharth Agarwal <sid0@fb.com> [Thu, 08 Oct 2015 14:18:43 -0700] rev 26574
filemerge._xmerge: drop no longer necessary 'if r:' check Cleanup from an earlier patch to make premerge be directly called from the main filemerge function.
Thu, 08 Oct 2015 14:17:31 -0700 filemerge._idump: drop no longer necessary 'if r:' check
Siddharth Agarwal <sid0@fb.com> [Thu, 08 Oct 2015 14:17:31 -0700] rev 26573
filemerge._idump: drop no longer necessary 'if r:' check Cleanup from an earlier patch to make premerge be directly called from the main filemerge function.
Thu, 08 Oct 2015 14:16:19 -0700 filemerge._merge: drop no longer necessary 'if r:' check
Siddharth Agarwal <sid0@fb.com> [Thu, 08 Oct 2015 14:16:19 -0700] rev 26572
filemerge._merge: drop no longer necessary 'if r:' check Cleanup from an earlier patch to make premerge be directly called from the main filemerge function.
Mon, 05 Oct 2015 02:33:45 -0700 revset: delete _updatedefaultdest as it has no users
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 02:33:45 -0700] rev 26571
revset: delete _updatedefaultdest as it has no users The revset is not used anywhere anymore. We delete the function until we use (and therefore test it again).
Mon, 28 Sep 2015 22:11:23 -0700 merge: get the default update destination from the function
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 28 Sep 2015 22:11:23 -0700] rev 26570
merge: get the default update destination from the function There is no value in using the revset instead of the extracted function.
Mon, 05 Oct 2015 01:46:47 -0700 update: move default destination computation to a function
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 01:46:47 -0700] rev 26569
update: move default destination computation to a function We ultimately want this to be accessible through a revset, but there is too much complexity here for that to work. Especially we'll have to return more than just the destination to control the behavior (eg: bookmarks to activate, etc). To prevent cycle, a new module is created, it will receive other destination/behavior function in the future.
Thu, 08 Oct 2015 10:57:03 -0700 worker: restore old countcpus code (issue4869)
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 08 Oct 2015 10:57:03 -0700] rev 26568
worker: restore old countcpus code (issue4869) This is a backout of d29859cfcfc2. The stdlib implementation of multiprocessing.cpu_count() attempts to invoke a process on BSD and Darwin platforms (at least on 2.7). Under certain conditions (such as cwd being removed) this could raise. Our old code was silently catching the exception. The old code was more robust, so restore it.
Wed, 07 Oct 2015 21:22:16 -0700 filemerge: call premerge directly from main merge function
Siddharth Agarwal <sid0@fb.com> [Wed, 07 Oct 2015 21:22:16 -0700] rev 26567
filemerge: call premerge directly from main merge function The merge code currently does (in pseudocode): for f in tomerge: premerge f merge f We'd like to change this to look more like: for f in tomerge: premerge f for f in tomerge: merge f This makes sure as many files are resolved as possible before prompting for the others. This restructuring is also necessary for custom merge drivers. This function separates out the premerge step from the merge step. In future patches we'll actually turn these into separate steps in the merge driver. The 'if r:' occurrences will be cleaned up in subsequent patches.
Mon, 05 Oct 2015 16:19:54 -0700 bundle2: allow lazily acquiring the lock
Durham Goode <durham@fb.com> [Mon, 05 Oct 2015 16:19:54 -0700] rev 26566
bundle2: allow lazily acquiring the lock In the external pushrebase extension, it is valuable to be able to do some work without taking the lock (like running expensive hooks). This enables significantly higher commit throughput. This patch adds an option to lazily acquire the lock. It means that all bundle2 part handlers that require writing to the repo must first call op.gettransction(), when in this mode.
Tue, 06 Oct 2015 14:42:29 -0700 bundle2: add op.gettransaction() to handlers that need the lock
Durham Goode <durham@fb.com> [Tue, 06 Oct 2015 14:42:29 -0700] rev 26565
bundle2: add op.gettransaction() to handlers that need the lock A future patch will allow the bundle2 lock be taken lazily. We need to introduce transaction-gets to each handler that needs the lock. The tests caught these issues when I added lazy locking.
Thu, 08 Oct 2015 17:44:22 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 08 Oct 2015 17:44:22 -0500] rev 26564
merge with stable
Thu, 01 Oct 2015 23:13:57 -0700 patchbomb: add a 'bundletype' config under 'patchbomb'
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 01 Oct 2015 23:13:57 -0700] rev 26563
patchbomb: add a 'bundletype' config under 'patchbomb' patchbomb relies on the 'hg bundle' command to generate an attached bundle using --bundle. However, while 'hg bundle' has a --type option, patchbomb did not. This is becoming very relevant since we are about to issue bundle2 for general-delta repository. This was tracked as issue4863
Wed, 07 Oct 2015 13:05:25 -0700 import: allow processing of extra part header after import
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 07 Oct 2015 13:05:25 -0700] rev 26562
import: allow processing of extra part header after import As we have a way for extension to add more header, we need a way for them to actually process them. We add a basic hook point to do extra work after the import have been committed.
Tue, 06 Oct 2015 09:51:24 -0700 import: allow processing of extra part header during import
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 09:51:24 -0700] rev 26561
import: allow processing of extra part header during import As we have a way for extension to add more header, we need a way for them to actually process them. We add a basic hook points to alter the changeset (especially extra) before we commit. There would be more to do for a full featured hooking, but this currently fit my needs.
Tue, 06 Oct 2015 02:23:21 -0700 extract: parse 'nodeid' using the generic mechanism
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:23:21 -0700] rev 26560
extract: parse 'nodeid' using the generic mechanism Parsing 'nodeid' is very simple and a good first test.
Tue, 06 Oct 2015 02:22:23 -0700 extract: parse 'branch' using the generic mechanism
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:22:23 -0700] rev 26559
extract: parse 'branch' using the generic mechanism Parsing 'branch' is very simple and a good first test.
Wed, 07 Oct 2015 01:13:36 -0700 extract: parse 'date' using the generic mechanism
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 07 Oct 2015 01:13:36 -0700] rev 26558
extract: parse 'date' using the generic mechanism Parsing 'date' is very simple and a good first test.
Wed, 07 Oct 2015 01:20:49 -0700 extract: add some facility for extensible header parsing
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 07 Oct 2015 01:20:49 -0700] rev 26557
extract: add some facility for extensible header parsing We need a way for extension to extend the header we can parse. We start with a very simple mechanism that will be used in the next changeset.
Tue, 06 Oct 2015 02:16:24 -0700 extract: remove the 'user' variable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:16:24 -0700] rev 26556
extract: remove the 'user' variable It is not heavily used enough to justify being something other than a dictionary entry.
Tue, 06 Oct 2015 02:11:09 -0700 extract: use a single return
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:11:09 -0700] rev 26555
extract: use a single return The differences between both returns are now very thin, we factor out that part.
Wed, 07 Oct 2015 00:50:53 -0700 extract: move 'nodeid' assignment where it is parsed
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 07 Oct 2015 00:50:53 -0700] rev 26554
extract: move 'nodeid' assignment where it is parsed The is one setter and no consumer, we can move it there directly.
Tue, 06 Oct 2015 02:08:32 -0700 extract: move 'date' assignment where it is parsed
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:08:32 -0700] rev 26553
extract: move 'date' assignment where it is parsed There is one setter and no consumer, we can move it there directly.
Tue, 06 Oct 2015 02:07:33 -0700 extract: assign user to 'data' earlier
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:07:33 -0700] rev 26552
extract: assign user to 'data' earlier This is used in both case, we can assign it once.
Tue, 06 Oct 2015 02:06:36 -0700 extract: move 'branch' assignment where it is parsed
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 06 Oct 2015 02:06:36 -0700] rev 26551
extract: move 'branch' assignment where it is parsed There is one setter and no consumer, we can move it there directly.
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.
(0) -10000 -3000 -1000 -300 -100 -64 +64 +100 +300 +1000 +3000 +10000 tip