rollback: don't clear the filecache This was an old workaround to force the filecache to reload everything. Now that the syncing issue is fixed, we no longer need it.

destroyed: keep the filecache in sync with __dict__ (issue3335) (issue3693) (issue3743) We need to make sure that if X is in the filecache then it's also in the filecache owner's __dict__, otherwise it will go out of sync: repo.X # first access to X, records stat info in # filecache and updates __dict__ repo._filecache.clear() # removes X from _filecache but it's still in __dict__ repo.invalidate() # iterates over _filecache and removes entries # from __dict__, but X isn't in _filecache, so # it's kept in __dict__ repo.X # X is fetched from __dict__, bypassing the filecache

localrepo: write the phasecache when destroying nodes

localrepo: update the branchmap when destroying nodes This was previously called directly during strip. Moving it to destroying also means that it'll be called through _rollback, which seems harmless.

localrepo: introduce destroying function

localrepo: don't refresh filecache entries that aren't in __dict__ We call invalidate to remove properties from __dict__ because they're possibly outdated and we'd like to check for a new version. Next time the property is accessed the filecache mechanism checks the current stat info with the one recorded at the last time the property was read, if they're different it recreates the property. Previously we refreshed the stat info on all properties in the filecache when the lock is released, including properties that are missing from __dict__. This is a problem because: l = repo.lock() repo.P # stat info S for P is recorded in _filecache <changes are made to repo.P indirectly, e.g. underlying file is replaced> # P's new stat info = S' l.release() # filecache refreshes, records S' as P's stat info At this point our filecache contains P with stat info S', but P's version is from S, which is outdated. The above happens during _rollback and strip. Currently we're wiping the filecache and forcing everything to reload from scratch which works but isn't the right solution.

changelog: please check-code and remove tabs Tabs were introduced in 06185554e7e3.

branchmap: Save changectx creation during update The newly introduced `branchmap` function allows us to skip the creation of changectx objects. This speeds up the construction of the branchmap. On the mozilla repository (117293 changesets, 15490 mutable) Before: ! impactable 19.9 ! mutable 0.576 ! unserved 3.16 After: ! impactable 7.03 (2.8x faster) ! mutable 0.352 (1.6x) ! unserved 1.15 (2.7x) On the cpython repository (81418 changesets, 6418 mutable) Before: ! impactable 15.9 ! mutable 0.451 ! unserved 0.861 After: ! impactable 6.55 (2.4x faster) ! mutable 0.170 (2.6x faster) ! unserved 0.289 (2.9x faster) On the pypy repository (58852 changesets) Before: ! impactable 13.6 After: ! impactable 6.17 (2.2x faster) On my Mercurial repository (18295 changesets, 2210 mutable) Before: ! impactable 23.9 ! mutable 0.368 ! unserved 0.057 After: ! impactable 1.31 (18x faster) ! mutable 0.042 (8.7x) ! unserved 0.025 (2.2x)

changelog: add a `branch` method, bypassing changectx The only way to access the branch of a changeset is currently to create a changectx object and access its `branch()` method. Creating a new Python object is costly and has a huge impact on code doing heavy access to `branch()` (like branchmap). This change introduces a new method on changelog that allows direct access to the branch of a revision. See the next changeset for impact.

branchmap: pass revision insteads of changectx to the update function Creation of changectx objects is very slow, and they are not very useful. We are going to drop them. The first step is to change the function argument type.

perf: add perfbranchmap command The command times the update of a branchmap from its nearest subset or from scratch.

clfilter: enforce hidden filtering on all repository accesses We ensure all repositores created through `mercurial.hg.repository` are "hidden" filtered. This is an even stronger enforcement than 5bb610f87d1d. Citing Matt's response to changeset 5bb610f87d1d installing filtering in dispatch: > Unfortunately, this means that code that doesn't go through dispatch (ie all > those crazy misguided people using Mercurial as a library) are going to see > these hidden changesets. > > Might be better to instead install the filter in localrepo construction by > default and disable it in dispatch.

archival: avoid touching deprecated gzip name attribute The existing workaround didn't work when no filename was specified. If running in a context with warnings enabled and subsecond mtime it gave a warning: DeprecationWarning: use the name attribute

archival: pass integer to struct.pack int field instead of float If running in a context with warnings enabled and subsecond mtime it gave a warning: DeprecationWarning: integer argument expected, got float

largefiles: fix update from a merge with removed files A situation with this case could happen after interrupting an update. Update would fail with: abort: No such file or directory: $TESTTMP/f/.hglf/sub2/large6 Update from a merge without using clean is not possible anyway, so this patch takes a step in the right direction so it gets as far as reporting the right error.

largefiles: fix revert removing a largefile from a merge Before revert could fail with: abort: .hglf/large@33fdd332ec64: not found in manifest! The LookupError will now be caught and handled correctly.

largefiles: remove unused proto.refuseclient code Should have been removed with other pre-1.9 code in 7c604d8c7e83.

subrepo: make 'in subrepo' string easier to find by external tools This patch is meant to make it easier for tools that wrap the mercurial output (such as TortoiseHg) to find the "in subrepo MYSUBREPO" string that (since 9e3910db4e78) is appended after subrepo error messages, particularly when the mercurial output is translated to a non-English language. The message remains the same but the '%s' that was used to prepend the original error message in front of the 'in subrepo' string has been moved out of the translatable string. As an example of the usefulness of making it easy to look for "in subrepo MYSUBREPO" strings, TortoiseHg looks for these strings in error messages in order to "linkify them" (i.e. convert "MYSUBREPO" into alink to the corresponding subrepo). The original string made it hard for a tool such as TortoiseHg to look for the translated string on mercurial's output because the translated string contained the error message itself. This meant that a regular expression was required to ignore the error message part. With this change TortoiseHg can just get the translated "(in subrepo %s)" string, substitute %s for the subrepo path (which it gets from the subrepo exception) and simply search for the resulting string (no regular expression needed, or at least a much simpler regular expression could be used). Additionaly, the existing string could lead a translator mistakenly assume that it was possible invert the order of the %s (error and subrepo path) fields, which would not work because the string interpolation was position based.

subrepo: fix python2.4 compatibility after 9aa6bee6e9f9 super(SubrepoAbort, self).__init__(*args, **kw) raises TypeError: super() argument 1 must be type, not classobj

test-keyword: improve grammar and spelling in branchcache note See: da9e544c69d6

Merge with stable.

repoview: extract hideable revision computation in a dedicated function This will help extensions to plug into the hidden mechanism.

largefiles: make update with backup files in .hglf slightly less broken Largefiles update would try to copy f to f.orig if there was a .hglf/f.orig . That is in many many ways very very wrong, but it also caused an abort if f didn't exist. Now it only tries to copy f if it exists.

tests: fix up test-highlight for breadcrumb changes

color: add template label function

templater: add no-op template function 'label'

posix: fix split() for the case where the path is at the root of the filesystem posixpath.split() strips '/' from the dirname *unless it is the root*. This patch reproduces this behavior in posix.split(). The old behavior causes a crash when creating a file at the root of the repo with localrepo.wfile() when the repo is at the root of the filesystem.

record: remove unused import

cvsps: fix indentation

hghave: introduce a test (unused) for cvs >= 1.12

discovery: drop the visibleheads function It has no users left. (Using filtering explicitly is easier.)

clfilter: remove the last usage of `visibleheads` We can just inline the filtering now that all server code uses changelog filtering directly.

discovery: drop the visiblebranchmap function

clfilter: drop extra filtering in wireprotocol The repository used by wireprotocol is already filtered. We no longer need to call special functions.

clfilter: filter "unserved" on all wireprotocol command calls This ensures that unserved changesets are not exposed through the wire protocol.

clfilter: drop extra filtering in localpeer The repository used by localpeer is already filtered. We no longer need to call a special function.

clfilter: make localpeer use a repo with "unserved" filter This changeset installs a broad filter on most repos used for serving. This removes the need to use the `visiblehead`/`visiblebranchmap` functions, and ensures that changesets we should not serve are in fact never served. We do not use filtering on hgweb yet, as there is still a number of issues to solve there.

performance: speedup computation of extinct revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. This change drops revset calls in favor of direct testing of the phase of changesets. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! extinct ! wall 0.015124 After: ! extinct ! wall 0.009424 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! extinct ! wall 0.032844 After: ! extinct ! wall 0.000066

performance: speedup computation of suspended revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. This change drops a revset call in favor of direct testing of the phase of changesets. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! suspended ! wall 0.014319 After: ! suspended ! wall 0.009559 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! suspended ! wall 0.033373 After: ! suspended ! wall 0.000053

performance: speedup computation of unstable revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. This change drops revset call in favor of direct testing of the phase of changesets. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! unstable ! wall 0.017366 After this changes: ! unstable ! wall 0.008093 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! unstable ! wall 0.045190 After: ! unstable ! wall 0.000032

performance: speedup computation of mutable revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. The "mutable" filter is used during branch cache loading operation. We need to make it fast. This change drops revset calls in favor of direct testing of the phase of a changeset. Performance test on my Mercurial checkout - 19857 total changesets, - 1646 mutable revision Before: ! mutable ! wall 0.032405 After: ! mutable ! wall 0.001469 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 mutable changeset, Before: ! mutable ! wall 0.188636 After: ! mutable ! wall 0.000022

performance: speedup computation of unserved revisions In their current state, revset calls can be very costly, as we test predicates on the entire repository. The "unserved" filter is used in multiple applications, and in particular in some branch cache loading operations. We need to make it fast. This change drops revset calls in favor of direct testing of the phase of a changeset. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! unserved ! wall 0.030477 After: ! unserved ! wall 0.011844 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! unserved ! wall 0.111259 After: ! unserved ! wall 0.000084

performance: speedup computation of hidden revisions In their current state, revset calls can be very costlys, as we test predicates on the entire repository. The hidden filter is very widely used, and needs to be very fast. This change drops revset calls in favor of direct revision manipulation. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! hidden ! wall 0.077553 After this changes: ! hidden ! wall 0.011230 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! hidden ! wall 0.389472 After: ! hidden ! wall 0.000079

performance: speedup computation of obsolete revisions In their current state, revset calls can be very costly as we test predicates on the entire repository. As obsolete computation is used by the "hidden" filter, it needs to be very fast. This changet drops the revset call in favor of direct testing of the phase of a changeset. Performance test on my Mercurial checkout - 19857 total changesets, - 1584 obsolete changesets, - 13310 obsolescence markers. Before: ! obsolete ! wall 0.047041 After: ! obsolete ! wall 0.004590 Performance test on a Mozilla central checkout: - 117293 total changesets, - 1 obsolete changeset, - 1 obsolescence marker. Before: ! obsolete ! wall 0.001539 After: ! obsolete ! wall 0.000017

clfilter: drop unnecessary explicit filtering on histedit Hidden changeset filtering is now done at repo level. The orphaned children computation will not include any (unless you add --hidden).

clfilter: drop unnecessary explicit filtering on rebase Hidden changeset filtering is now done at repo level. The rebaseset computation will not include any (unless you add --hidden).

clfilter: ensure that hidden filtering is working on all commands Now that hidden changeset are filtered for all commands, we test the behavior of `heads` and `summary` regarding hidden changeset.

clfilter: enforce hidden changeset globally The dispatch code now enables filtering of "hidden" changesets globally. The filter is installed before command and extension invocation. The `--hidden` switch is now global and disables this filtering for any command. Code in log dedicated to changeset exclusion is removed as this global filtering has the same effect.

record: use patch.diffopts to account for user diffopts This allows user defined diff options (e.g. showfunc) to be accounted for when using record. A test has been updated accordingly.

convert: fix most test-check-code-hg violations in cvsps code

tests: update hgweb tests to include breadcrumbs

subrepo: add subrepo property to SubrepoAbort exceptions This new property contains the path of the subrepo that generated the exception. This information can then be used by GUI tools such as TortoiseHg.

tests: update test-convert-cvs*.t The preceding commit caused their outputs to change.

cvsps: use commitids (when present) to detect changesets Simplify core logic by no longer attempting to work around missing class attributes. Instead always generate the attributes and ignore the cache if the attributes are missing

hgweb, spartan: link from manifest title to changeset page

hgweb, spartan: add "URL breadcrumbs" This change adds a "URL breadcrumb" to the "title" of the pages on the spartan template. By title I mean the first line that is shown right below the page selection row, which shows the name of the page that is being viewed, along with some additional information. In doing so it standarizes those "titles" which now follow the pattern: URL breadcumb / page details

hgweb: add a "URL breadcrumb" to the index and repository pages The purpose of this change is to make it much easier to navigate up the repository tree when the hg web server is used to serve more than one repository. A "URL breadcrumb" is a path where each of the path items can be clicked to go to the corresponding path page. This lets you go up the folder hierarchy very quickly. For example, when showing the list of repositories in http://myserver/myteams/myprojects, the following "breadcrumb" will be shown: Mercurial > myteams > myprojects Clicking on "myprojects" reloads the page. Clicking on "myteams" goes up one folder. Clicking on the leftmost "Mercurial" goes to the server root. This "breadcrumb" also appears on all repository pages. For example on the summary page of the repository at http://myserver/myteams/myprojects/myrepo the following will be shown: Mercurial > myteams > myprojects > myrepo / summary This change has been applied to all templates that already had a link to the main repository page (i.e. gitweb, monoblue, paper and coal) plus to the index page of the spartan template. In order to make the breadcumb links stand out the some of the template styles have been customized.

merge: never do premerge on symlinks Simplemerge is not symlink aware and will never do the right thing on symlinks.

merge: make internal merge fail cleanly on symlinks Simplemerge is not symlink aware and will never do the the right thing on symlinks. It would read the symlink as a file and abort with 'No such file or directory' on dangling symlinks. Instead, internal:merge now simply fails to merge symlinks.

debugpushkey: list keys sorted