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.