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.

tests: improve description of hgweb secret bookmarks test Added in 886936ecc21b with only an issue number to describe it.

bookmarks: show active bookmark even if not at working dir If the active bookmark doesn't point at a parent of the working dir (e.g. a pull moved it out from under us), we nonetheless show it as active. This follows on 2096e025a728 in removing the dichotomy (at least in the UI) between "current" and "active" bookmarks.

hgweb: don't attempt to show hidden bookmarks (issue3774) localrepository._bookmarks is unfiltered, but hgweb gets a filtered repo. This fixes the resulting traceback on the 'bookmarks' page.

hgweb: fetch tipmost unfiltered rev thru the changelog This fixes a traceback when tip is filtered (e.g. because it's secret). See issue3783, for which this is a partial fix.

help: update verbose 'clone' help to include '@' bookmark

tests: fix test-help.t for '@' bookmark documentation e031e10cdc06 unexpectedly introduced bookmarks into the results for 'hg help -k clone'. Mea culpa, miserere &c.

help: document '@' bookmark in 'help bookmarks' and 'help clone'

revset: evaluate sub expressions correctly (issue3775) Before this patch, sub expression may return unexpected result, if it is joined with another expression by "or": - "^"/parentspec(): "R or R^1" is not equal to "R^1 or R". the former returns only "R". - "~"/ancestorspec(): "R or R~1" is not equal to "R~1 or R". the former returns only "R". - ":"/rangeset(): "10 or (10 or 15):" is not equal to "(10 or 15): or 10". the former returns only 10 and 15 or grater (11 to 14 are not included). In "or"-ed expression "A or B", the "subset" passed to evaluation of "B" doesn't contain revisions gotten from evaluation of "A", for efficiency. In the other hand, "stringset()" fails to look corresponding revision for specified string/symbol up, if "subset" doesn't contain that revision. So, predicates looking revisions up indirectly should evaluate sub expressions of themselves not with passed "subset" but with "entire revisions in the repository", to prevent "stringset()" from unexpected failing to look symbols in them up. But predicates in above example don't so. For example, in the case of "R or R^1": 1. "R^1" is evaluated with "subset" containing revisions other than "R", because "R" is already gotten by the former of "or"-ed expressions 2. "parentspec()" evaluates "R" of "R^1" with such "subset" 3. "stringset()" fails to look "R" up, because "R" is not contained in "subset" 4. so, evaluation of "R^1" returns no revision This patch evaluates sub expressions for predicates above with "entire revisions in the repository".

test-rebase: add another test for rebase with multiple roots This test the case when a Merge is dropped.

update: update to current bookmark if it moved out from under us (issue3682) If the current bookmark (the one listed in .hg/bookmarks.current) doesn't point to a parent of the working directory, e.g. if it was moved by a pull, use that as the update target instead of the tipmost descendent. A small predicate is (finally) added to the bookmarks module to check whether the current bookmark is also active.

test-bookmarks-pushpull.t: don't set bookmark active unnecessarily The test in question doesn't have anything to do with having an active bookmark. This change makes the test change the two bookmarks it affects without making them active. It clears the way for adding a test for updating to an active bookmark that moved out from under us.

doc: use "tag" revset predicate instead of "tagged" for example in help "tag" predicate is officially described in help, but "tagged" is not, even though the latter works as same as the former.

tests: add regression tests for another revrange edge case These tests would've passed before ac0c12123743 and e441657b372b. Inserting them to make sure that continues to be the case.

graphmod: don't try to visit nullrev (issue3772)

log: remove any ancestors of nullrev (issue3772) For the special case, ":null" we remove the implied revision 0 since that wouldn't make any sense here. A test case is added to make sure only nullrev is shown.

help: add documentation for new template functions

changectx: fix the handling of `tip` We can not use `len(repo,changelog)`, it may be a filtered revision. We now use `repo,changelog.tip()` to fetch this information. The `tip` command is also fixed and tested Thanks goes to Idan Kamara for the initial report.

bisect: use changelog for iteration With changelog filtering, we can not use xrange anymore. We have to use the changelog to do the iteration. This way, the changelog excludes filtered revision and we can safely use what we iterate over. Without this changes, bisect crash with a traceback if there is filtered revision in the repo. Tests have been updated.

documentation: update to new filter names Changeset f3b21beb9802 change filter names but forgot some documentation updates.

largefiles: enhance error message to make it more i18n-friendly

merge with i18n

largefiles: fix largefiles+subrepo update (issue3752) Override updaterepo() instead of individual methods that may not be called for each subrepo. Add test. Based on patch from Matt Harbison. Changes the order of update-related messages (now largefiles comes before the global status).

debugsuccessorssets: fix typos in docstring

i18n-pt_BR: synchronized with f5fbe15ca744

merge: only sort manifests in debug mode (issue3769)

Added signature for changeset f5fbe15ca744

Added tag 2.5-rc for changeset f5fbe15ca744

merge default into stable for 2.5 code freeze

pathencode: don't use alloca() for safety/portability

branchmap: display filtername when `updatebranch` fails to do its jobs We have a very handy assert at the ends of `branchmap.updatecache` that check the resulting branchmap is actually valid. I know we do not like assert in mercurial but this one is very handy for debugging. There is really not reason for `branchmap.updatecache` to have this kind of issue but this happened and handful of time during the development of this or introduction of other related feature. I advice to keep it around until we are a bit more confident with the new code.

scmutil: localize and improve 'not under root' message

run-tests.py: don't let hg run interactively in debug mode In normal test mode stdin is closed and hg is thus not interactive. In --debug mode stdin is inherited from the running console and to the tests, and hg could thus wait in prompts when running on Windows. See http://selenic.com/pipermail/mercurial-devel/2013-January/047548.html . Instead set ui.interactive=False to make Mercurial non-interactive. Other commands might still work differently in the --debug environment. This should solve the problem with hg waiting for input but still make it possible to add --debugger to hg in a test and run run-tests.py with --debug.

run-tests.py: backout "don't use console for stdin when running in debug mode" f5842787a958 caused that some kind of interactive debugging no longer was possible - such as running hg with --debugger in a test run with run-tests.py --debug .

rebase: properly handle unrebased revision between rebased one With rebase taking multiple roots it is possible to have revision in the "rebase domain" not rebased themself. We do not want rebased revision above them to be detached. We want such revision to be rebased on the nearest rebased ancestors. This allows to preserve the topology of the rebase set as much a possible To achieve this we introduce a new state `revignored` which informs `defineparents` of the situation. The test in `test-rebase-obsolete.t` was actually wrote and his now fixed.

rebase: lose the comparison to `nullmerge` For a proper behavior of the `--rev` revision we will need another possible state for revision ignored by rebase. We alter the comparison to `nullmerge` to match this future lower state too.

repoview: cache filtered changelog Creating a new changelog object for each access is costly and prevents efficient caching changelog side. This introduced a x5 performance regression in log because chunk read from disk were never reused. We were jumping from about 100 disk read to about 20 000. This changeset introduce a simple cache mechanism that help the last changelog object created by a repoview. The changelog is reused until the changelog or the filtering changes. The cache invalidation is much more complicated than it should be. But MQ test show a strange cache desync. I was unable to track down the source of this desync in descent time so I'm not sure if the issue is in MQ or core. However given the proximity to the 2.5 freeze, I'm choosing the inelegant but safe route that makes the cache mechanism safer.

rebase: do not invent successor to skipped changeset When rebase results in an empty a changeset it is "skipped" and no related changeset is created at all. When we added obsolescence support to rebase (in fc2a6114f0a0) it seemed a good idea to use its parent successor as the successors for such dropped changesets. (see old version of the altered test). This option was chosen because it seems a good way to hint about were the dropped changeset "intended" to be. Such hint would have been used by automatic evolution mechanism to rebase potential unstable children. However, field testing of this version are not conclusive. It very often leads to the creation of (totally unfounded) evolution divergence. This changeset changes this behavior and mark skipped changesets as pruned (obsolete without successors). This prevents the issue and seems semantically better probably a win for obsolescence reading tool. See example bellow for details: User Babar has five changesets of interest: - O, its current base of development. - U, the new upstream - A and C, some development changesets - B another development changeset independent from A O - A - B - C \ U Babar decides that B is more critical than the A and C and rebase it first $ hg rebase --rev B --dest U B is now obsolete (in lower case bellow). Rebase result, B', is its successors.(note, C is unstable) O - A - b - C \ U - B' Babar is now done with B', and want to rebase the rest of its history: $ hg rebase --source A --dest B' hg rebase process A, B and C. B is skipped as all its changes are already contained in B'. O - U - B' - A' - C' Babar have the expected result graph wise, obsolescence marker are as follow: B -> B' (from first rebase) A -> A' (from second rebase) C -> C' (from second rebase) B -> ?? (from second rebase) Before this changeset, the last marker is `B -> A'`. This cause two issues: - This is semantically wrong. B have nothing to do with A' - B has now two successors sets: (B',) and (A',). We detect a divergent rewriting. The B' and A' are reported as "divergent" to Babar, confusion ensues. In addition such divergent situation (divergent changeset are children to each other) is tricky to solve. With this changeset the last marker is `B -> ø`: - This is semantically better. - B has a single successors set (B',) This scenario is added to the tests suite.

repoview: protect `base` computation from weird phase root If for some reason the phase roots contains nullid, the set of filtered revs will contains -1. That confuse Mercurial a lot. In particular this corrupt the branchcache. Standard code path does not result in nullid phase root. It can only result from altered `.hg/store/phaseroots` or buggy extension. However better safe than sorry.

posix: don't compare atime when determining if a file has changed A file's atime might change even if the file itself doesn't change. This might cause us to invalidate caches more often than necessary. Before this change, hg add often resulted in the dirstate being parsed twice on systems that track atime. After this change, it is only parsed once. For a repository with over 180,000 files, this speeds up hg add from 1.2 seconds to 1.0.

hg: replace DirCleanup class with normal try/finally use

histedit: proper phase conservation (issue3724) Before this changeset, histedit created all new changesets according phases.new-commit option without any regards for the phases of the original changesets. This changeset fix that using the phase of rewritten changeset to decide the phase of the resulting changeset. In case of reordering or folding, we keep secret item secret as it seems the safer path. temporary commit creation are not affected. They are head only and stripped at the end of the histedit. As for the resolution of issue3681 (obsolescence cycle prevention), we do not handle changesets created by edit command.

test-histedit: reorder phases test and prepare for more We are going to add a lot regarding phase of test while fixing issue3724. This movement allows to put them after this first phase test.

test-histedit: fix instability creation test The current test does not rewrite anything and therefor does not create any instability. We also clean up the repo state after the test. This required the rebase extension.