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.