1. The problem with `hg strip` is how it is (and has to be) implemented, because of the revlog format. Basically, revlogs store changesets in chronological orde

1. The problem with `hg strip` is how it is (and has to be) implemented, because of the revlog format. Basically, revlogs store changesets in chronological order. Stripping a branch means first saving all commits that are not being stripped (but occur chronologically after the first stripped commit) to a bundle, then truncating the revlog before the first stripped commit, then restoring the commits from the bundle. This can already be an expensive operation locally, but it's even more of a problem on a server shared by multiple users who may have been pushing their own commits. 2. The general recommendation would be to use `hg prune` (part of the evolve extension) instead. Pruning commits will just hide the pruned commits and pushing will then send the obsolescence markers for those commits to the server, hiding them there, too. This is an append-only operation, so it's cheap and works well even with multiple users. 3. In general, though, it is a problem that Git and Mercurial treat remote branches/repositories as second class citizens. This is something that Bazaar got right: Bazaar abstracts over the storage, so (except where limited by network performance) you can do pretty much anything on a remote branch/repo that you can do locally.