commands: support creating stream clone bundles Now that we have support for recognizing the streaming clone bundle type, add a debug command for creating them. I decided to create a new debug command instead of adding support to `hg bundle` because stream clone bundles are not exactly used the same way as normal bundle files and I don't want to commit to supporting them through the official `hg bundle` command forever. A debug command, however, can be changed without as much concern for backwards compatibility. As part of this, `hg bundle` will explicitly reject requests to produce stream bundles. This command will be required by server operators using stream clone bundles with the clone bundles feature.

exchange: support for streaming clone bundles Now that we have a mechanism to produce and consume streaming clone bundles, we need to teach the human-facing bundle specification parser and the internal bundle file header reading code to be aware of this new format. This patch does so. For the human-facing bundle specification, we choose the name "packed" to describe "streaming clone bundles" because the bundle is essentially a "pack" of raw revlog files that are "packed" together. There should probably be a bikeshed over the name, especially since it is human facing.

streamclone: support for producing and consuming stream clone bundles Up to this point, stream clones only existed as a dynamically generated data format produced and consumed during streaming clones. In order to support this efficient cloning format with the clone bundles feature, we need a more formal, on disk representation of the streaming clone data. This patch introduces a new "bundle" type for streaming clones. Unlike existing bundles, it does not contain changegroup data. It does, however, share the same concepts like the 4 byte header which identifies the type of data that follows and the 2 byte abbreviation for compression types (of which only "UN" is currently supported). The new bundle format is essentially the existing stream clone version 1 data format with some headers at the beginning. Content negotiation at stream clone request time checked for repository format/requirements compatibility before initiating a stream clone. We can't do active content negotiation when using clone bundles. So, we put this set of requirements inside the payload so consumers have a built-in mechanism for checking compatibility before reading and applying lots of data. Of course, we will also advertise this requirements set in clone bundles. But that's for another patch. We currently don't have a mechanism to produce and consume this new bundle format. This will be implemented in upcoming patches. It's worth noting that if a legacy client attempts to `hg unbundle` a stream clone bundle (with the "HGS1" header), it will abort with: "unknown bundle version S1," which seems appropriate.

spelling: fix typo in transaction error messages

transaction: reorder unlinking .hg/journal and .hg/journal.backupfiles After this reordering, absence of '.hg/journal' just before starting new transaction means also absence of '.hg/journal.backupfiles'. In this case, all temporary files for preceding transaction should be completely unlinked, and HG_PENDING doesn't cause unintentional reading stalled temporary files in. Otherwise, 'repo.transaction()' raises exception with "run 'hg recover' to clean up transaction" hint.

merge: make in-memory changes visible to external update hooks 51844b8b5017 (while 3.4 code-freeze) made all 'update' hooks run after releasing wlock for visibility of in-memory dirstate changes. But this breaks paired invocation of 'preupdate' and 'update' hooks. For example, 'hg backout --merge' for TARGET revision, which isn't parent of CURRENT, consists of steps below: 1. update from CURRENT to TARGET 2. commit BACKOUT revision, which backs TARGET out 3. update from BACKOUT to CURRENT 4. merge TARGET into CURRENT Then, we expects hooks to run in the order below: - 'preupdate' on CURRENT for (1) - 'update' on TARGET for (1) - 'preupdate' on BACKOUT for (3) - 'update' on CURRENT for (3) - 'preupdate' on TARGET for (4) - 'update' on CURRENT/TARGET for (4) But hooks actually run in the order below: - 'preupdate' on CURRENT for (1) - 'preupdate' on BACKOUT for (3) - 'preupdate' on TARGET for (4) - 'update' on TARGET for (1), but actually on CURRENT/TARGET - 'update' on CURRENT for (3), but actually on CURRENT/TARGET - 'update' on CURRENT for (4), but actually on CURRENT/TARGET Root cause of the issue focused by 51844b8b5017 is that external 'update' hook process can't view in-memory changes (especially, of dirstate), because they aren't written out until the end of transaction (or wlock). Now, hooks can be invoked just after updating, because previous patches made in-memory changes visible to external process. This patch may break backward compatibility from the point of view of "scheduling hook execution", but should be reasonable because 'update' hooks had been executed in this order before 3.4. This patch tests "hg backout" and "hg unshelve", because the former activates the transaction before 'update' hook invocation, but the former doesn't.

hook: centralize passing HG_PENDING to external hook process This patch centralizes passing HG_PENDING to external hook process into '_exthook()'. To make in-memory changes visible to external hook process, this patch does: - write (or schedule to write) in-memory dirstate changes, and - set HG_PENDING environment variable, if: - a transaction is running, and - there are in-memory changes to be visible This patch tests some commands with some hooks, because transaction activity of a same hook differs from each other ("---": "not tested"). ======== ========= ========= ============ command preupdate precommit pretxncommit ======== ========= ========= ============ unshelve o --- --- backout x --- --- import --- o o qrefresh --- x o ======== ========= ========= ============ Each hooks are examined separately to prevent in-memory changes from being visible to external process accidentally by side effect of hooks previously invoked.

cmdutil: make in-memory changes visible to external editor (issue4378) Before this patch, external editor process for the commit log can't view some in-memory changes (especially, of dirstate), because they aren't written out until the end of transaction (or wlock). This causes unexpected output of Mercurial commands spawned from that editor process. To make in-memory changes visible to external editor process, this patch does: - write (or schedule to write) in-memory dirstate changes, and - set HG_PENDING environment variable, if: - a transaction is running, and - there are in-memory changes to be visible "hg diff" spawned from external editor process for "hg qrefresh" shows: - "changes newly imported into the topmost" before 49148d7868df(*) - "all changes recorded in the topmost by refreshing" after this patch (*) 49148d7868df changed steps invoking editor process Even though backward compatibility may be broken, the latter behavior looks reasonable, because "hg diff" spawned from the editor process consistently shows "what changes new revision records" regardless of invocation context. In fact, issue4378 itself should be resolved by 800e090e9c64, which made 'repo.transaction()' write in-memory dirstate changes out explicitly before starting transaction. It also made "hg qrefresh" imply 'dirstate.write()' before external editor invocation in call chain below. - mq.queue.refresh - strip.strip - repair.strip - localrepository.transaction - dirstate.write - localrepository.commit - invoke external editor Though, this patch has '(issue4378)' in own summary line to indicate that issues like issue4378 should be fixed by this. BTW, this patch adds '-m' option to a 'hg ci --amend' execution in 'test-commit-amend.t', to avoid invoking external editor process. In this case, "unsure" states may be changed to "clean" according to timestamp or so on. These changes should be written into pending file, if external editor invocation is required, Then, writing dirstate changes out breaks stability of test, because it shows "transaction abort!/rollback completed" occasionally. Aborting after editor process invocation while commands below may cause similar instability of tests, too (AFAIK, there is no more such one, at this revision) - commit --amend - without --message/--logfile - import - without --message/--logfile, - without --no-commit, - without --bypass, - one of below, and - patch has no description text, or - with --edit - aborting at the 1st patch, which adds or removes file(s) - if it only changes existing files, status is checked only for changed files by 'scmutil.matchfiles()', and transition from "unsure" to "normal" in dirstate doesn't occur (= dirstate isn't changed, and written out) - aborting at the 2nd or later patch implies other pending changes (e.g. changelog), and always causes showing "transaction abort!/rollback completed"

dirstate: show develwarn for write() invocation without transaction This is used to detect 'dirstate.write()' invocation without the value gotten by 'repo.currenttransaction()' (mainly focused on 3rd party extensions).

dirstate: make dirstate.write() callers pass transaction object to it Now, 'dirstate.write(tr)' delays writing in-memory changes out, if a transaction is running. This may cause treating this revision as "the first bad one" at bisecting in some cases using external hook process inside transaction scope, because some external hooks and editor process are still invoked without HG_PENDING and pending changes aren't visible to them. 'dirstate.write()' callers below in localrepo.py explicitly use 'None' as 'tr', because they can assume that no transaction is running: - just before starting transaction - at closing transaction, or - at unlocking wlock

dirstate: remove layering violation around writing dirstate out This violation, which passes repo object to dirstate, was introduced by 09bb1ee7e73e. This patch uses 'False' instead of 'None' as default value of 'tr' argument, to distinguish "None as repo.currenttransaction() result" from "legacy invocation without explicit tr passing".

dirstateguard: remove layering violation around saving/restoring backup This violation, which passes 'repo' object to dirstate, was introduced by 59b5e8844eb0 and 020b12d591f3.

rebase: reduce scope of try catch in restorestate Refactoring by reduce the scope of the try catch block so that it only captures what it needs. I could have made it smaller but another patch in the series will add onto it.

rebase: on abort delete rebase state file no matter what When a user's repository is in an unfinished rebase state and they choose to abort, at a minimum, the repo should be out of that state. We've found situations where the user could not leave the state unless manually deleting the rebasestate file. This fix ensures that no matter what exception may be raised during the abort, the rebase state file will be deleted, the user will be out of the rebase state and they can get their repository into a workable condition.

contrib: make editmerge look for merge markers at the beginning of the line This fix adds a caret to the start of the regex looking for merge markers. This avoids the issue arises when you've real merge conflicts in a file that tests for the existance of merge markers in test output. Editmerge will not open on the fake/tested merge markers because they'll be indented in.

commit: abort when a committemplate is not changed If a committemplate is provided and no message is provided on the command line, and no edits are made to the commit template, then abort the commit.

localrepo.commit: disallow commit when driver-resolved files exist This code will not currently be activated because there's no code to mark files as driver-resolved in core. This point is also somewhat hard to plug into from extensions.

merge.mergestate: add a generator for driver-resolved files Just like for unresolved files above, we need to be able to tell what files are driver-resolved.

hook: for python hooks, also return whether an exception was raised The hook code treats python hooks raising an exception and returning True as the exact same. This is OK for hooks themselves, but other code that wants to invoke external code using the same underlying code is a bit more interested in making a distinction.

hook.runhooks: return a dict of result values This will be useful to other calling code that would be interested in what the individual hooks return.

hook: factor out determination of hooks from running them This will allow other code to run a predetermined series of hooks.

mq: generate patch names from first line of description Avoid the pointless numeric rev.diff patch names. Instead, do like mbox extension does and create meaningful patch names.

contrib: offer Python 2.7.10

contrib: drop Python < 2.6 from Makefile.python

mergetools.rc: find OSX FileMerge in the new location inside Xcode 4.3

exchange: don't print error codes after clone bundle failure We don't appear to print error codes elsewhere. The error codes are inconsistent between at least Linux and OS X and are more trouble than they are worth. Humans care about the error string more than the code anyway. A glob was also added to pave over differences in error strings between Linux and OS X.

debian: install bash completion as hg and not mercurial (issue4900)

merge-tools: allow marking a mergetool as completely disabled Very often in my life I'm finding that the only configured merge tool present on the system is vimdiff[0], and it's currently impossible (as far as I can tell) short of specifying `ui.merge = `[1] to actually *disable* a merge tool. This allows vimdiff-haters to put: [merge-tools] vimdiff.disable = yes in their ~/.hgrc and never see vimdiff again. I'm stopping short of putting this as a commented out entry in the sample new user hgrc (seen when a user runs `hg config --edit` with no ~/.hgrc) for now, but I might come back and do that later. 0: vimdiff is at an awkward intersection: it's usually installed by the vim package which is often installed as a vi substitute, so it's mere presence doesn't imply me wanting it, unlike (say) kdiff3. 1: There's a related problem I ran into today where specifying `ui.merge = :merge` failed because :merge isn't a command, which I think is a regression. I'll try and figure that out and at least file a bug.

exchange: add oparg to push so that extensions can wrap pushop

destmerge: extract logic based on branch heads in its own function One of the main goal of having consolidated destination function is to allow extension to play with this logic. We extract sub logic to make is wrapping more practical.