bookmarks: primarily use repo lock, not wlock Bookmarks are repository data, not working directory data. Only the current bookmark is working directory data. Some lock shuffling is required to avoid lockout between the initial mock lock and locking of the localrepo instance that is created after copying.

localrepo: update branchcache in a more reliable way test-mq-cache.t did apparently look at stale cache content. Testing with different locking mechanism happened to update the cache more frequently and thus caused a test failure.

tests: make qnew in test-mq-caches.t stable The unstable hashes did for other reasons not show up in the test output.

localrepo: remove spurious updatebranchcache return value - it was left over from the refactoring in d01e28657429.

mq: only save dirty files once when savedirty is called multiple times

mq: remove early wlock release in qnew It seems like something that missed the refactoring in 97b734fb9c6f.

mq: use .invalidate to cancel dirty mq state when cancelling transaction Before the code optimistically relied on savedirty not being called a cancelled transaction. If it was called it could save incorrect data. Instead we now start using the invalidate method introduced in b169ba60eebe.

mq: make qsave implementation more explicit It wasn't obvious from the code how qsave mocked around with .hg/patches and .hg/patches.? and what was going on. This makes it more explicit so it will survive future refactorings.

mq: consistently use boolean values for dirty flags

mq: minor cleanup

tag: lock before tagging

tests: lock before creating transaction in test-filelog

debugbuilddag: lock repo before starting transaction

rebase: take locks in the right order repo.lock was taken before repo.wlock - that could in principle cause a deadlock.

tests: keep track of all check-code.py warnings

filectx: typo in comment

keyword: update filectx.cmp monkeypatch to handle '\1\n' at start of file Analogous to 012b285cf643.

bugzilla: make XMLRPC interface support http and https access Inadvertently support is currently only for https. For some reason I thought xmlrpclib.SafeTransport did http and https, but it is https only. So create http and https XMLRPC transports that retain cookies. Decide which to use by inspecting the Bugzilla URL.

merge with stable

merge with i18n

i18n-ru: editorial for 'abort' and 'pipe'

i18n-ru: editorial for 'diff' * * * i18n-ru: editorial for 'diff'

i18n-ru: editorial for 'guard'

i18n-ru: vocabulary edited, minor corrections in translations.

i18n-ru: using correct abbreviated units for megabytes. See http://ru.wikipedia.org/wiki/МБ

help: fix column alignment in "hg help" output The output of "hg help" is changed to ensure that the column containing descriptions of commands, extensions, and other topics is correctly alignmened.

minirst: simplify and standardize field list formatting The default width of field lists is changed from 12 to 14 to align minirst with the rst2html tool. Shrinking the width of the left column to fit the content is removed, to keep formatting simple and uniform.

largefiles: correctly download new largefiles when merging There is a bug in the merge process where, if a new largefile is introduced in a merge and the user does not have that largefile in his repo's local store nor in his system cache, the working copy will retain the old largefile. Upon the commit of the merge, the standin is re-written to contain the hash of the old largefile, and the lfdirstate retains a "Modified" status for the file. The end result is that the largefile can show up in the merge commit as "Modified", but the standin has no diff. This is wrong in two ways: 1) Such a "wedged" history with a nonsense change in a commit should not be possible 2) It effectively reverts a largefile to an old version when doing a merge This is caused by the fact that the updatelfiles() command always checks the current largefile's hash against the hash stored in the current node's standin. This is correct behavior in every case except for a merge. When merging, we must assume that the standin in the working copy contains the correct hash, because the original hg.merge() has already updated it for us. This patch fixes the issue by patching the repo object to carry a "_ismerging" attribute, that the updatelfiles() command checks for. When this attribute is found, it checks against the working copy's standin, rather than the standin in the current node.

tests: add htmlcov option

run-tests: use a list comprehension instead of map

tests: fix omit path list All directories need a trailing asterisk. Otherwise the files are not excluded from coverage.

commands: partial backout of fbb68b382040

phase: add metavar to -r help text

phase: the REV argument can be repeated

commands: no need to rename merge and phases on import

phase: there is actually no -C option

phase: use standard syntax for command line flags We don't mark them as literal text and we mention the short option the first time we talk about a given flag.

phase: fix RST markup (use ``...`` for literal text)

phase: lowercase option help, rephrase slightly

filectx: fix cmp() of file starting with '\1\n' If file data starts with '\1\n', it will be escaped in the revlog to create an empty metadata block, thus adding four bytes to the size in the revlog size index. There's no way to detect that this has happened in filelog.size() faster than decompressing each revision [1]. For filectx.cmp(), we have the size of the file in the working directory available. If it differs by exactly four bytes, it may be this case, so do a full comparison. [1]: http://markmail.org/message/5akdbmmqx7vq2fsg

merge with stable

merge with i18n

merge with i18n

i18n-pt_BR: synchronized with e6c44dbe902f

merge with i18n

i18n-ru: spellcheck

i18n-ru: editorial for vocabulary words. Edited for: backup, bundle, repository, checkout

i18n-ru: editorial for hg help hgignore