merge: make all action tuples have the same length - keep args as tuple

merge: delay prompts a bit and show them in (extra) sorted order Preparing for backout of 760c0d67ce5e. The number of prompts will for all relevant cases be significantly smaller than the total number of files in the manifests. We can thus afford to sort the prompts more than we can afford to sort the manifests.

commit: show active bookmark in commit editor helper text If there is an active bookmark while committing, the bookmark name will be visible inside the commit message helper, below the branch name. This should make easier for the user to detect a mistaken commit parent, while working for example with a bookmark centric workflow like topic branches. The active bookmark is checked to be in the working directory, as pointed by Kevin Bullock, because otherwise committing would not advance it. In other words, this would not show the active bookmark name if the user changed the working tree parents with 'hg debugsetparents', for example.

dates: support 'today' and 'yesterday' in parsedate (issue3764) Adding support to parsedate in util module to understand the more idiomatic dates 'today' and 'yesterday'. Added unified tests and docstring tests for added functionality.

revset: change ancestor to accept 0 or more arguments (issue3750) Change ancestor to accept 0 or more arguments. The greatest common ancestor of a single changeset is that changeset. If passed no arguments, the empty list is returned.

merge with stable

Added signature for changeset a6088c05e43a

Added tag 2.5 for changeset a6088c05e43a

test-obsolete: now gets 404 for hidden change

merge with i18n

i18n-pt_BR: added message from crew 0324a1d88a53

i18n-pt_BR: added message from crew 9fbeb61b8ad2

i18n-ja: synchronized with 2a1fac3650a5

i18n-pt_BR: synchronized with 68eecbaf1bd3

hgweb: urlescape all urls, HTML escape repo/tag/branch/... names Without this, repository paths or names containing e.g. & characters or html tags yielded strange results, possibly allowing cross-site scripting attacks.

merge with crew

hgweb: rename 'currentbaseline' template keyword to 'basenode' Shorter and clearer. This keyword represents the node we're currently diffing against.

hgweb: rename 'changesetbaseline' template to 'difffrom' More accurately reflects what it will be used for, and is also shorter. This template is used to change which rev the current rev is diff'd against. For example, if you're at '/rev/P1:REV', this would link to a path like '/rev/P2:REV'. Example usage in a template: {parent%difffrom}

hgweb: add a `web.view` to control filtering This options add a new `web.view` to control filter level of hgweb. This option have two purposes: 1) Allow fall back to unfiltered version in case a yet undetected by critical bug is found in filtering after 2.5 release 2) People use hgweb as a local repoviewer. When they have secret changesets, they wants to use "visible" filter not "served" (modified by mpm, documentation deferred)

hgweb: returns 404 for unknow revision instead of 500 I noticed that access to filtered revision returned HTTP 500 code (internal server error). Investigation shown that it was the case for unknown revision too. That wrong and we now properly return a 404 for revision not found.

subrepo: allows to drop courtesy phase sync (issue3781) Publishing server may contains draft changeset when they are created locally. As publishing is the default, it is actually fairly common. Because of this "inconsistency" phases synchronization may be done even to publishing server. This may cause severe issues for subrepo. It is possible to reference read-only repository as subrepo. Push in a super repo recursively push subrepo. Those pushes to potential read only repo are not optional, they are "suffered" not "choosed". This does not break because as the repo is untouched the push is supposed to be empty. If the reference repo locally contains draft changesets, a courtesy push is triggered to turn them public. As the repo is read only, the push fails (after possible prompt asking for credential). Failure of the sub-push aborts the whole subrepo push. This force the user to define a custom default-push for such subrepo. This changeset introduce a prevention of this error client side by skipping the courtesy phase synchronisation in problematic situation. The phases synchronisation is skipped when four conditions are gathered: - this is a subrepo push, (normal push to read-only repo) - and remote support phase - and remote is publishing - and no changesets was pushed (if we pushed changesets, repo is not read only) The internal config option used in this version is not definitive. It is here to demonstrate a working fix to the issue. In the future we probably wants to track subrepo changes and avoid pushing to untouched one. That will prevent any attempt to push to read-only or unreachable subrepo. Another fix to prevent courtesy push from older clients to push to newer server is also still needed.

tests: fix toctou race in tinyproxy.py (issue3795) test-http-proxy.t sometimes failed with: File ".../tests/tinyproxy.py", line 110, in _read_write data = i.recv(8192) error: (104, 'Connection reset by peer') This might have started showing up with a9fd11ffa13f ... but it has apparently also been seen before. I don't see anything in a9fd11ffa13f that can explain it. It seems to be a race in test, in the tinyproxy helper: Tinyproxy found an incoming socket using select(). It would break the loop if an error had been detected on the socket, but there was no error and it tried to recv() from the socket. That failed - apparently because it had been reset after select(). Errors in the recv() will now be caught and will break the loop like errors detected by select() would. (send() could also fail in a similar way ... but using the same solution there and losing data we have read doesn't feel right.)

rebase: mention --rev in the help This changeset adds a small mention of it in the help to prevent confusion. This small addition references online help that is easier to update and improve at release time. Following Wagner Bruna's advice, this is added in a plain new paragraph to not invalidate current translation this close to the release.

hgweb: remove baseline info from paper template The user interface introduced in d605a82cf189 is not considered ready for prime time yet. The internal code stays in place for custom template usage. The feature is ultimately wanted and will be re-enabled soon. The current issue is only related to the visual of the current interface.

rebase: mention phases in the help Mention that Mercurial helps you not do what you've just been warned not to do, with a reference to the 'phases' help topic (not the 'phase' command help). Thanks to Pierre-Yves David <pierre-yves.david@ens-lyon.org> for motivating this change and Wagner Bruna <wagner.bruna+mercurial@gmail.com> for advising on how to do it in an i18n-friendly way.

hgwebdir: use web.prefix when creating url breadcrumbs (issue3790) The web.prefix setting was being ignored when creating the index URL breadcrumbs. We only need to fix hgwebdir and not hgweb because hgweb gets the complete URL request, including the prefix, while hgwebdir gets a "subdir" which does not include the prefix. This fix is slightly different of what was suggested on the bug tracker. In there it was suggested to hide the prefix itself from the breadcrumb. I think that would be a better solution, but it would require changing all the index templates and passing the prefix to the template engine, which may be too big a change for stable during the freeze. For now this fixes the problem, and the fix could be improved during the next cycle.

rebase: delete divergent bookmarks on destination (issue3685) Similar to merge, divergent bookmarks are only deleted when the bookmark is on the destination parent.

bookmarks: factor out delete divergent code Deleting divergent bookmarks is more generally useful than just in bookmarks.update.

rebase: remove bogus nullmerge check in updatebookmarks nstate[v] is a node, not an int, and the nullmerge check was done while building nstate anyway.

share: backout fd903f89e42b, except the test Locating the share source when no default path is available is now handled in subrepo._abssource(), so unconditionally setting a default path (and the associated problems) can be avoided. The test change reflects the fact that a default path is no longer set on the resulting share.

subrepo: use sharepath if available when locating the source repo This is an alternative fix for issue3518, enabling sharing of repositories with subrepos, without unconditionally setting the default path in the resulting repo's hgrc file. Better test coverage is added here, but won't prove this code is working until fd903f89e42b is backed out. The problem with the original fix is, if a default path is not available to be copied over from the share source, the default path on the resulting repo is set to the source location. Since that's where the actual repository is stored, the path is essentially self-referential, so push, pull, incoming and outgoing effectively operate on itself. While incoming and outgoing make it look like nothing was changed, push currently hangs (see issue3657). In this case where there is not a real default path, these operations should abort with "default(-push) not found", like the source repo would. Note this problem with the original fix affected repos without subrepos too.

test-histedit: add tests for dropping head changeset I got bug report from user in this specific case. I was unable to reproduce in test situation. Testing this situation is still valuable.

tests: use `pwd` instead of ${PWD} in test-convert-git.t - because of Solaris

histedit: prevent parent guessed via --outgoing from being a revset (issue3770) If the binary hash of the parent node guessed via --outgoing happened to contain a special revset character (":" was specified in the bug), the revset parser would abort. Hexlifying the node before passing it to the revsingle call should fix that.

tests: fix for windows - slashes and no serve

merge: fix UnboundLocalError (issue3791) A wrong variable name was introduced in 384df4db6520 for a case without test coverage. The variable name is fixed and a test case is introduced.

parsers: fix memleak of revlog cache entries on strip Since 12a852c7c763, raw_length can be reduced on strip, but corresponding cache entries still have refcount. They are not dereferenced by _index_clearcache(), and never freed. To reproduce the problem, run "hg pull" and "hg strip null" several times in the same process.

hgweb: fix navigation label (issue3792) Latest refactoring (6da1e979340a) was buggy and used a variable from another loop. Tests are run on repo too small to cache that.

profiling: add documentation of lsprof 'sort' and 'nested'

OS X: try cheap ascii .lower() in normcase before making full unicode dance This is similar to what is done in encoding.lower, introduced in c481761033bd. This has been seen making 'hg up' and 'hg st' in a 50000+ files repo 13% faster. This might make Mercurial slightly slower for users who mainly use non-ASCII filenames. That is a reasonable trade-off.

run-tests.py: inherit PYTHONHASHSEED from environment if set This makes it possible to fix the seed by using for instance PYTHONHASHSEED=7 ./run-tests.py ... This can be very convenient when trying to debug problems that are influenced by hash values. Try different seed values until you find one that triggers the bad behaviour and then keep that while debugging. The value 0 will restore default Python behavior and disable randomization.

test-obsolete: validate that bundle is not affected by issue3788 Bundle might have been affected by the same kind of error than pull (issue3788). Testing show it is not the case.

pull: fix crash when pulling changeset that get hidden locally (issue3788) When you have obsolescence marker that apply to a pulled changesets, the added changeset is immediately filtered. Then the list of added changeset needs to be build against and unfiltered repo.

hgweb: prevent traceback during search when filtered (issue3783) The search needs to iterate over the repo using changelog.revs like the rest of the Mercurial code.

bookmarks: hide bookmarks on filtered revs from listkeys Don't expose unserved changesets to remote repos. Thanks to Sean Farley <sean.michael.farley@gmail.com> for tracking down the issue and Pierre-Yves David <pierre-yves.david@ens-lyon.org> for the fix.

bookmarks: don't use bookmarks.listbookmarks in local computations bookmarks.listbookmarks is for wire-protocol use. The normal way to get all the bookmarks on a local repository is repo._bookmarks.

filtering: test that bookmarks prevent hiding of changesets

discovery: outgoing pass unfiltered repo to findcommonincoming (issue3776) We noa pass an unfiltered repo in the same way `localrepo.push` does. This does not alter outgoing behavior and prevents possible crash with computing common/missing. The `findcommonincoming` code could be simplified to make this unnecessary, but this is too much change for the freeze.

test: minor documentation fix The related test check push, not pull.

largefiles: fix cat when using relative paths from subdirectory

largefiles: fix commit when using relative paths from subdirectory Remove cwd handling from getstandinmatcher - it did not belong there, as proven by the tests.

largefiles: allow use of urls with #revision largefiles tried to create a peer directly with the specified url. That caused abort: unsupported URL component: "..." if a revision was specified in the url. The branch name do not matter for largefiles' use of remote peers. Largefiles will be shared among all branches anyway.

largefiles: don't verify largefile hashes on servers when processing statlfile When changesets referencing largefiles are pushed then the corresponding largefiles will be pushed too - unless the target already has them. The client will use statlfile to make sure it only sends largefiles that the target doesn't have. The server would however on every statlfile check that the content of the largefile had the expected hash. What should be cheap thus became an expensive operation that trashed the disk and the cache. Largefile hashes are already checked by putlfile before being stored on the server. A server should thus be able to keep its largefile store free of errors - even more than it can keep revlogs free of errors. Verification should happen when running 'hg verify' locally on the server. Rehashing every largefile on every remote stat is too expensive. Clients will also stat lfiles before downloading them. When the server verified the hash in stat it meant that it had to read the file twice to serve it. With this change the server will assume its own hashes are ok without checking them on every statlfile. Some consequences of this change: - in case of server side corruption the problem will be detected by the existing check on the client side - not on server side - clients that could upload an uncorrupted largefile when pushing will no longer magically heal the server (and break hardlinks) - a client will now only upload its uncorrupted files after the corrupted file has been removed on the server side - client side verify will no longer report corruption in files it doesn't have (Issue3123 discussed related problems - and how they have been fixed.)

tests: clarify test for pushing corrupted largefile The test no longer tested that the server prevented pushing a corrupt largefile. At the same time it tested what happened when the server already had a corrupt largefile. These two cases are now separated.

largefiles: verify all files in each revision and report errors in any revision Verify used 'any' and would stop verifying after the first failure in each changeset. The exit code only reported the result from the last changeset.

tests: better test coverage of largefiles localstore verify This demonstrates problems that will be fixed later.

largefiles: adapt remotestore._getfile to batched statlfile 9e1616307c4c introduced batching of statlfile, but not all codepaths got converted. _getfile gave _stat garbage and got garbage back. The garbage didn't match the expected error codes and was thus interpreted as success. It could thus end up trying to fetch a largefile that didn't exist. Instead we now pass _stat valid input and handle both correct and invalid output correctly. This makes the code work as intended ... but it would probably be better if it didn't abort on missing largefiles, just like it happened to do before.

largefiles: don't allow corruption to propagate after detection basestore.get uses util.atomictempfile when checking and receiving a new largefile ... but the close/discard logic was too clever for largefiles. Largefiles relied on being able to discard the file and thus prevent it from being written to the store. That was however too brittle. lfutil.copyandhash closes the infile after writing to it ... with a 'blecch' comment. The discard was thus a silent noop, and as a result of that corruption would be detected ... and then the corrupted files would be used anyway. Instead we now use a tmp file and rename or unlink it after validating it. A better solution should be implemented ... but not now.

largefiles: adapt verify to batched remote statlfile (issue3780) 9e1616307c4c introduced batching of statlfile, but not all codepaths got converted. 'hg verify' with a remotestore could thus crash with TypeError: 'builtin_function_or_method' object is not iterable Also, the 'hash' variable was used without assigning to it. Don't use variable names that collide with Python built-in functions. Instead we use 'expecthash' as in localstore. The tests for this issue covers an untested area. The tests happens to also reveal incorrect attempts at getting non-existing largefiles, bad server side handling of that, and corruption issues - all to be fixed later.

largefiles: let wirestore._stat return stats as expected by remotestore verify - preparing for fixing verify crash.