amend: invalidate dirstate in case of failure (issue3670) The temporary commit created by amend update the dirstate. If the final commit fails, we need to invalidate the change made to the dirstate, otherwise the release of the wlock will write the dirstate created after the rollbacked temporary commit. This dirstate writing logic should probably be handled in the same object than the transaction one. However such change are too big for stable.

i18n-ru: delete loose letter

i18n-ru: synchonized with 777084ac8416

paper: sanity-check page feed links filelog has feeds in header, but not in menu bar help has header feeds pointing to tags

zeroconf: use port from server instead of picking port from config (issue3746) In order to get the port, wrap create server instead of hgweb_mod/hgwebdir_mod.

scmutil: don't try to match modes on filesystems without modes (issue3740)

hgwebdir: honor web.templates and web.static for static files (issue3734)

zeroconf: use port from server instead of picking port from config (issue3746) In order to get the port, wrap create server instead of hgweb_mod/hgwebdir_mod.

branchmap: enable caching for filtered version too The `_branchcache` attribute is turned into a dictionary. Key are filter name and value is a `branchcache` object. Unfiltered version is cached as `None` filter. The attribute is renamed to `_branchcaches` to avoid confusion with the previous one. Both old and new contents are dictionary even if their contents are different. I prefer possible extension code to crash right away instead of just messing the wrong dictionary. As all different caches work isolated to each other, this code keeps the previous behavior of using the unfiltered cache we nothing is filtered. This is a cheap way to have cache collaborate and nullify potential impact in the default case.

branchmap: report filtername when read fails Now that we can have multiple one, we need to know which filecache failed to be read from disk.

branchmap: use a different file name for filtered view of repo

clfilter: ensure unfiltered repo have a filtername attribute too That will allows to use `repo.filtername` for dispatch purpose.

branchmap: move the cache file name into a dedicated function Filtered view of the repo will want to write they file name in a different file.

branchmap: read and write key part related to filtered revision Now that we have a third part for the cache key we need to write and read it on disk. It is only written when there is filtered revision. This keep the format compatible with older version. Notes that, at this state, filtered repository does not use any disk caches yet.

check-code: disallow defunct <> operator Added a test for that and one other python3 check in test-check-code.t.

largefiles: stop using <> operator in favor of != <> has been deprecated for a while, and != is futureproof

commands: fix implicit tuple that is invalid syntax in Python3

check-code: disallow two-argument form of raise Using this old form makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

httpclient: apply change df9aea1def3e: remove use of two-argument raise

test-symlink-os-yes-fs-no.py: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

scmutil: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

url: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

win32: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

commandserver: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

test-command-template.t: fix test so it all year This test started failing for me after midnight UTC on December 31st. Fixed it by specifying a date 7 years in the future more precisely (rather than just adding 8 to the year and specifying January 1st), which allows the test to pass both now and on 2012-12-01 at the same time.

cmdutil: make getgraphlogrevs limit-aware For a repository with over 400,000 changesets, this speeds up graphlog with a small limit by around 0.05 seconds (~50%).

cmdutil: stop pretending we can calculate revs for graphlog lazily cmdutil.getgraphlogrevs does a ton of work trying to build a graphlog lazily, and then cmdutil.graphlog comes along and destroys all of that. graphmod.dagwalker requires that it be given the full list of revs upfront so that it can perform filtering and tests against known revs. For a repository with over 400,000 changesets, this speeds up graphlog by around 0.02 seconds (~20% with a small limit).

cmdutil: store a local ref to repo.hiddenrevs in getgraphlogrevs On a repository with over 400,000 changesets, this speeds graphlog up by around 0.03 seconds (~20% with a small limit).

cmdutil: make getgraphlogrevs return revs in descending order

branchmap: takes filtered revision in account for cache calculation Tracking tipnode and tiprev is not enough to ensure validaty of the cache as they do not help distinguish a cache that ignored various revisions below tiprev. To detect such difference, we build a hash of all ignored revisions. This hash is then used when checking the validity of a cache for a repo.

branchmap: improve computation of target tip With revision filtering the effective revision number of "tip" may be lower than: len(changelog) - 1 We now use a more correct version preventing useless writing on disk in some case.

branchmap: improve invalid cache message when reading This factors out the generation of the message. This helps future error reporting when reading cache for filtered repository.

histedit: allow operation from non-head if obsolete is enabled Obsolescence markers can represent this situation just fine. Rewritten revisions are marked as precursors of the ones creates by histedit. Unaffected descendants become "unstable". If obsolescence is not enabled we keep the current behavior of aborting. This new behavior only applies when obsolete is enabled and is subject to future discussion and changes.

rebase: allow non-head rebase-set when obsolete is enabled Obsolescence markers can represent this situation just fine. Rebased revisions are marked as precursors of the ones create by rebase. Unrebased descendants becomes "unstable". If obsolescence is not enabled we keep the current behavior of aborting. This new behavior only applies when obsolete is enabled and is subject to future discussion and changes.

amend: allow amend of non-head when obsolete is enabled Obsolescence marker can represent this situation just fine. The old version is marked as precursor of the new changeset. All its descendants become "unstable". If obsolescence is not enabled we keep the current behavior of aborting. This new behavior only applies when obsolete is enabled and is subject to future discussion and changes.

obsolete: factorise troubles detection during push The use of the two methods introduced earlier allows a factorisation of the push code preventing push of troubled changeset.

obsolete: introduce a troubles method on context A troubled changeset may be affected by multiple trouble at the same time. This new method returns a list of all troubles affecting a changes.

obsolete: introduce a troubled method on context Allows to quickly check if a changeset is affected by any troubles. (troubles are: unstable, bumped and divergent)

tests: fix windows test failures

merge with stable

tests: fix windows test failures

largefiles: better test coverage of wireproto and the http protocol

largefiles: cleanup of warnings on errors getting largefiles Especially the "no default or default-push path set in hgrc" was often very misleading and didn't give any hint where it actually was looking. A long error messages is better than several multi-line messages.

largefiles: remove trivial portability wrappers

largefiles: remove reporemove portability wrapper

largefiles: remove findoutgoing portability wrapper

largefiles: use constant for '.hglf/' Problem: '.hglf' + '/' was computed in some tight loops. There is no need for that.

largefiles: use plain wjoin instead of the complex pathto

largefiles: unindent code

largefiles: simplify lfdirstate ignore handling - it is only for tracking .hglf

largefiles: rename 'admin' to more descriptive 'lfstoredir'

largefiles: simplify lfutil.getstandinmatcher by inlining getmatcher

largefiles: remove overly complex handling of ignored and unknown files

largefiles: introduce basic debugstate --large functionality Very useful for debugging largefiles "performance" issues. This is used for testing 03faf12fbee7.

util: fold ENOENT check into unlinkpath, controlled by new ignoremissing flag Refactor a common pattern.

merge with stable

largefiles: don't walk through all ignored files Problem: 'hg status' with largefiles enabled would walk through all the files that .hgignore said should be ignored. That made it slow if a lot of files were .hgignored or the cache was cold. It seems like there was a reason to this, but other improvements has rendered this unnecessary. Solution: .hgignore is now only ignored when that is requested (--ignore). This is a minimal 'stable' change. There is room for other improvement.

largefiles revert: update lfdirstate with result from first cleanliness check Largefiles revert do for some reason have two lfdirstates and lfdirstatestatus invocations in one function. The result from the first lfdirstate check was however not written back to the lfdirstate, and some files was thus checked twice.

largefiles status: update lfdirstate with result from cleanliness check Problem: 'hg status' kept checking largefiles with an unknown state until some other command wrote the updated dirstate. Solution: Add missing lfdirstate.write().

bundlerepo: don't return the peer without bundlerepo from getremotechanges Problem: getremotechanges would return the 'other' repo if nothing was incoming and there thus wasn't any bundle to base the repo on. The 'other' could be a http peer which only implement the functionality available over the http protocol. Transplant could thus fail with TypeError: argument of type 'httppeer' is not iterable Solution: Return the local repo instead of the remote peer if there is no reason to place a bundlerepo on top of the local repo.

strip: do not update branchcache during strip (issue3745) At this moment, the cache is invalid, and will be thrown away. Later the strip function will call the `localrepo.destroyed` method that will update the branchmap cache.

copies: do not track backward copies, only renames (issue3739) The inverse of a rename is a rename, but the inverse of a copy is not a copy. Presenting it as such -- in particular, stuffing it into the same dict as real copies -- causes bugs because other code starts believing the inverse copies are real. The only test whose output changes is test-mv-cp-st-diff.t. When a backwards status -C command is run where a copy is involved, the inverse copy (which was hitherto presented as a real copy) is no longer displayed. Keeping track of inverse copies is useful in some situations -- composability of diffs, for example, since adding "a" followed by an inverse copy "b" to "a" is equivalent to a rename "b" to "a". However, representing them would require a more complex data structure than the same dict in which real copies are also stored.

copies: make debug messages more sensible The -> in debug messages is currently overloaded to mean both source to dest and dest to source. To fix this, we add explicit labels and make the arrow direction consistent.

copies: separate moves via directory renames from explicit copies Currently the "copy" dict contains both explicit copies/moves made by a context and pending moves that need to happen because the other context moved the directory the file was in. For explicit copies, the dict stores a destination to source map, while for pending moves via directory renames, it stores a source to destination map. The merge code uses this fact in a non- obvious way to differentiate between these two cases. We make this explicit by storing these pending moves in a separate dict. The dict still has a source to destination map, but that is called out in the docstring.