config: use absolute_import

changelog: use absolute_import

changegroup: use absolute_import

bundlerepo: use absolute_import

bundle2: use absolute_import

branchmap: use absolute_import

bookmarks: use absolute_import

archival: use absolute_import

ancestor: use absolute_import A few months ago, import-checker.py was taught to enforce a more well-defined import style for files with absolute_import. However, we stopped short of actually converting source files to use absolute_import because of problems with certain files. Investigation revealed the following problems with switching to absolute_import universally: 1) import cycles result in import failure on Python 2.6 2) undetermined way to import C/pure modules While these problems need to be solved, they can be put off. This patch starts a series of converting files to absolute_import that won't exhibit any of the aforementioned problems.

discovery: always use batching now that all peers support batching Some peers will transparently downgrade batched requests to non-batched ones, but that simplifies code for everyone using batching.

wireproto: make wirepeer look-before-you-leap on batching This means that users of request batching don't need to worry themselves with capability checking. Instead, they can just use batching, and if the remote server doesn't support batching for some reason the wirepeer code will transparently un-batch the requests. This will allow for some slight simplification in a handful of places. Prior to this change, largefiles would have been silently broken against a server which did not support batching.

batching: migrate basic noop batching into peer.peer "Real" batching only makes sense for wirepeers, but it greatly simplifies the clients of peer instances if they can be ignorant to actual batching capabilities of that peer. By moving the not-really-batched batching code into peer.peer, all peer instances now work with the batching API, thus simplifying users. This leaves a couple of name forwards in wirepeer.py. Originally I had planned to clean those up, but it kind of unclarifies other bits of code that want to use batching, so I think it makes sense for the names to stay exposed by wireproto. Specifically, almost nothing is currently aware of peer (see largefiles.proto for an example), so making them be aware of the peer module *and* the wireproto module seems like some abstraction leakage. I *think* the right long-term fix would actually be to make wireproto an implementation detail that clients wouldn't need to know about, but I don't really know what that would entail at the moment. As far as I'm aware, no clients of batching in third-party extensions will need updating, which is nice icing.

parsers: fix memory leak in compute_phases_map_sets PySet_Add increments the reference of the added object to the set, see: https://hg.python.org/cpython/file/2.6/Objects/setobject.c#l379 Before this patch we were forgetting to decrement the reference count after adding objects to the phaseset. This patch fixes the issue and makes the reference count right so that these objects can be properly garbage collected.

histedit: do not stay on a cleaned nodes on abort There is case where nodes are neither in tmpnodes nor leaf but still get removed. For example, if you used the "edit" action, made a commit and run --abort. The commit you made is not tracked by histedit, yet it will likely be cleaned up with its parent. The commit may not tracked because no replacements computations are done in the --abort case.

histedit: also update away from tmpnodes The working copy may be on a tmpnodes, we need to update away before it is stripped from the repository.

histedit: use revset to check if we need to update during abort The for loop is already quite more complicated than necessary and we are about to add some logic. Instead, we use a simple revset. Revset laziness should provide us with similar performance.

histedit: remove useless 'else' clause This 'else: pass' clause have no effect. We drop it for clarity.

histedit: make cleanupnode more robust The goal of this function is to strip content out of the repository. We do not really care if this content is visible or cleanup node not and we should proceed anyway. None of the internal actions are subject to this, however, a third party extension running arbitrary commands during histedit is affected by this.

convert: fix git convert using servers branches The conversion from git to hg was reading the remote branch list directly from the origin server. If the origin's branch had moved forward since the last git fetch, it would return a git hash which didn't exist locally, and therefore the branch was not converted. This changes it to rely on the local repo's refs/remotes list of branches instead, so it's completely cut off from the server.

revrange: drop old-style parser in favor of revset (API) Now revset can parse nullary ":" operator and existing "foo+bar" tags, we don't need the old-style parser. This means scmutil.revsingle(), revpair() and revrange() no longer accept a binary nodeid. An integer revision is still allowed as it isn't ambiguous.

tag: do not pass binary nullid to scmutil.revsingle() Future patches will remove the old-style parser that happen to accept a binary nodeid. A binary nodeid shouldn't be passed to scmutil.revrange() because it is ambiguous. For example, bin('20' * 19 + '30') is valid binary nodeid, but it can also be parsed as a revset expression, '0'.

revset: port parsing rule of old-style ranges from scmutil.revrange() The old-style parser will be removed soon.

debugrevspec: pass lookup function to visualize fallback mechanism The next patch will move the exceptional parsing of old-style ranges to revset.tokenize(). This patch will allow us to see the result tree. Note that the parsing result of '-a-b-c-' is incorrect at this changeset. It will be fixed soon.

help: fix typo familar -> familiar

highlight: exit early on textual and unknown files (issue3005) When highlight extension encountered files that pygments didn't recognize, it used to fall back to text lexer. Also, pygments uses TextLexer for .txt files. This lexer is noop by design. On bigger files, however, doing the noop highlighting resulted in noticeable extra CPU work and memory usage: to show a 1 MB text file, hgweb required about 0.7s more (on top of ~3.8s, Q8400) and consumed about 100 MB of RAM more (on top of ~150 MB). Let's just exit the function when it's clear that nothing will be highlighted. Due to how this pygmentize function works (it modifies the template in-place), we can just return from it and everything else will work as if highlight extension wasn't enabled.

histedit: extract a simpler function to process replacement on abort The process replacement is building a full mapping to allow moving bookmarks and creating obsolescence marker. We do not need the full logic for abort so we extract it. It will be useful as abort is missing some data about the replacement and can crash when third party extensions push it a bit too far.

merge with stable

exchange: fix dead assignment The assignment of the value from bundle2.processbundle() to 'r' is unused. It is currently the same as its third argument (if given), and since that argument may eventually go away (according to the method's docstring), let's reassign the return value to 'op' instead to better prepare for that.

exchange: s/phase/bookmark/ in _pushb2bookmarks()

histedit: backout ebb5bb9bc32e The faulty changeset use obsolescence marker to roll the repository back on --abort. This is a problematic approach because --abort should be as close as an actually transaction rollback as possible stripping all created data from the repository (cf `hg rebase --abort` stripping all created changesets). Instead ebb5bb9bc32e made all content created during the aborted histedit still available in the repository adding obsolescence marker to make them hidden. This will cause trouble to evolution user as a re-run of the same histedit (with success) will likely result in the very same node to be "recreated" while obsolescence marker would be in place for them. And canceling an obsoletion is still a fairly complicated process. This also rollback using obsmarkers instead of strip to clean up temporary node on successful histedit run because the two change were not split in separated changeset. Rolling that part back does not have significant consequence a will have to be resubmitted independently

test-bookmarks.t: avoid nested repo This is (a) pretty unnecessary and (b) breaks tests for the third-party hgwatchman extension, which doesn't support nested repos.

revlog: remove unused shaoffset constants Call sites were removed at 61c9bc3da402, "revlog: remove lazy index".

revlog: correct comment about size of v0 index format

merge with stable

Added signature for changeset 21aa1c313b05

Added tag 3.5 for changeset 21aa1c313b05

i18n: fix unclosed inline span in pt_BR This was causing test-gendoc.t to complain: WARNING: Inline interpreted text or phrase reference start-string without end-string.

merge with i18n

i18n-ja: synchronized with 7fcad0c4ef8c

convert: when converting from Perforce use original local encoding by default On Windows Perforce command line client uses default system locale to encode output. Using 'latin_1' causes locale-specific characters to be replaced with question marks. With this patch we will use default locale by default whilst allowing to specify it explicity with 'convert.p4.encoding' config option. This is a potentially breaking change for any scripts relying on output treated as in 'latin_1' encoding. Also because hgext.convert.convcmd overwrites detected default system locale with UTF-8 we had to introduce an import cycle in hgext.convert.p4 to retrieve originally detected encoding from hgext.convert.convcmd.

i18n-pt_BR: synchronized with 3e84f40232c7

convert: when getting file from Perforce concatenate data at the end As it turned out, even when getting relatively small files, concatenating string data every time when new chunk is received is very inefficient. Maintaining a string list of data chunks and concatenating everything in one go at the end seems much more efficient - in my testing it made getting 40 MB file 7 times faster, whilst converting of a particularly big changelist with some big files went down from 20 hours to 3 hours.

help: scripting help topic There are a lot of non-human consumers of Mercurial. And the challenges and considerations for machines consuming Mercurial is significantly different from what humans face. I think there are enough special considerations around how machines consume Mercurial that a dedicated help topic is warranted. I concede the audience for this topic is probably small compared to the general audience. However, lots of normal Mercurial users do things like create one-off shell scripts for common workflows that I think this is useful enough to be in the install (as opposed to, say, a wiki page - which most users will likely never find). This text is by no means perfect. But you have to start somewhere. I think I did cover the important parts, though.

convert: document convert.hg.startrev

transplant: restore dirstate correctly at unexpected failure Before this patch, transplant can't restore dirstate as expected at failure other than one while patching. This causes: - unexpected file status - dirstate refers already rollback-ed parent (only at failure of transplanting the 2nd or later revision) To restore dirstate correctly also at unexpected failure, this patch encloses scope of store lock and transaction by 'dirstateguard'. This is temporary fixing for stable branch. See DirstateTransactionPlan wiki page for detail about the future plan to treat dirstate consistently around scope boundary of transaction. https://mercurial.selenic.com/wiki/DirstateTransactionPlan This patch also adds 'if lock' examination for safety 'lock.release()', because creating 'dirstateguard' object may fail unexpectedly (e.g. IOError for saving dirstate). BTW, in the test script, putting section header '[extensions]' into '.hg/hgrc' is needed to fix incomplete disabling 'abort' extension at 4d1382fd96ff.

localrepo: make journal.dirstate contain in-memory changes before transaction Before this patch, in-memory dirstate changes aren't written out at opening transaction, even though 'journal.dirstate' is created directly from '.hg/dirstate'. Therefore, subsequent 'hg rollback' uses incomplete 'undo.dirstate' to restore dirstate, if dirstate is changed and isn't written out before opening transaction. In cases below, the condition "dirstate is changed and isn't written out before opening transaction" isn't satisfied and this problem doesn't appear: - "wlock scope" and "transaction scope" are almost equivalent e.g. 'commit --amend', 'import' and so on - dirstate changes are written out before opening transaction e.g. 'rebase' (via 'dirstateguard') and 'commit -A' (by separated wlock scopes) On the other hand, 'backout' may satisfy the condition above. To make 'journal.dirstate' contain in-memory changes before opening transaction, this patch explicitly invokes 'dirstate.write()' in 'localrepository.transaction()'. 'dirstate.write()' is placed before not "writing journal files out" but "invoking pretxnopen hooks" for visibility of dirstate changes to external hook processes. BTW, in the test script, 'touch -t 200001010000' and 'hg status' are invoked to make file 'c' surely clean in dirstate, because "clean but unsure" files indirectly cause 'dirstate.write()' at 'repo.status()' in 'repo.commit()' (see fe03f522dda9 for detail) and prevents from certainly reproducing the issue.

dirstate: ensure mv source is marked deleted when walking icasefs (issue4760) Previously, importing a case-only rename patch on a case insensitive filesystem caused the original file to be marked as '!' in status. The source was being forgotten properly in patch.workingbackend.close(), but the call it makes to scmutil.marktouched() then put the file back into the 'n' state (but it was still missing from the filesystem). The cause of this was scmutil._interestingfiles() would walk dirstate, and since dirstate was able to lstat() the old file via the new name, was treating this as a forgotten file, not a removed file. scmutil.marktouched() re-adds forgotten files, so dirstate got out of sync with the filesystem. This could be handled with less code in the "kind == regkind or kind == lnkkind" branch of dirstate._walkexplicit(), but this avoids filesystem accesses unless case collisions occur. _discoverpath() is used instead of normalize(), since the dirstate case is given first precedence, and the old file is still in it. What matters is the actual case in the filesystem.

extdiff: allow modifications in subrepos to be copied back This check was a legacy bit from when the file data was being fetched manually with 'ctx[wfn]', but archive() does that now. 49966b5ab16f seems to indicate that this avoided a problem where a merge adds a file to another branch, and that test still passes. Unfortunately, I don't see a way to create a test that modifies the file in the temporary directory before the command exits. I wonder if the os.lstat() call needs to be wrapped in an exception handler for the case where archive didn't create a file because the file didn't exist in that revision. But I wasn't able to trigger a problem without it on a real repository.

ignore: fix path concatenation of .hgignore on Windows Since 3de48ff62733, .hgignore is ignored on Windows because a pat may have a drive letter, but pathutil.join is posixpath.join. "z:\foo\bar/z:\foo\bar\.hgignore" Instead, this patch uses os.path.join() and util.localpath() to process both parts as file-system paths. Maybe we can remove os.path.join() at dirstate._ignore because 'include:' is resolved relative to repo root? It was introduced by a04c7b74b3d5.

repair: fix typo in warning message

monoblue: link to branches on summary page "Tags" and "Bookmarks" sections on this page already have the similar links, and so does the "Branches" on summary page in gitweb, so let's do the same in monoblue.

monoblue: fix branches link on help topics page

hgweb: show ages in repos' Last modified column in monoblue and gitweb Index page, which shows the list of available repositories, has a column where the last modification date for each repo is shown. paper, coal and spartan already show the dates in relative format (e.g. "2 weeks ago"), because these styles have the required process_dates() js function call in their footer templates, which are included on every page. But monoblue and gitweb styles have more things in the footer templates, such as repo name and its atom/rss links, so they don't include the footer on index page (as this page doesn't have a single repo context). Let's call process_dates() without including the footer.

ignore: fix include: rules depending on current directory (issue4759) When reading pattern files, we just call open(path), which is relative to the current directory. Let's fix this by resolving the paths before attempting to read the file.

test: move ignore test run into a subdirectory Previously the hgignore test just called hg init in the test directory. A future patch needs to test hgignore stuff from outside of the repo, so let's move the entire test repo into a subdirectory.

monoblue: show relative age of bookmarks In b24e5a708fad, age calculation was made dynamic (i.e. in javascript), but for some reason bookmarkentry template in monoblue/map got a wrong class. It resulted in /summary and /bookmarks pages always showing exact dates for bookmarks, no age calculation was performed. Let's fix this by using "age" class that is already used in branchentry and tagentry templates in the same map file. As usual, the exact date for such elements is still available in title attribute, so it shows in a tooltip on hover.