Share extension with narrow

Background

In narrow repos, both the repo store and the working copy is narrow. The tracked paths can be specified at clone time and can be updated later using the hg tracked command. Note that the use of "tracked" here is different from its use in e.g. "untracked files".

The share extension lets you create one or more "shares" of a repo where each share has its own working copy (and dirstate), but they all share the store with the main repo.

Problem

When using share with a narrow repo, any changes to the tracked paths will affect the shared store, but will not affect any other share's working copy. The narrowness of the working copy and dirstate thus get out of sync with the narrowness of the store.

Solution

Keep track of narrowspec separately for store and working copy. Detect when there's a mismatch and error out. Provide the user with a command to update the working copy and the dirstate with the new narrowspec. The narrowspec associated with the working copy will be used only for detecting conflicts; it will not be used for e.g. walking the dirstate.

Updating the dirstate and working copy

When narrowing, files that are not known to be clean (timestamp etc do not match the ones recorded in the dirstate) will be left behind (we may want to tell the user about such files). When widening, any existing files will be left in place (will not be replaced by clean version from manifest). Taken together, this means that if the store becomes narrower and then wider again, the working directory will be back in the same state it was.

The update of working copy and dirstate we already do when widening/narrowing could potentially be removed and we can rely on them getting updated later. But we may be able to do it more efficiently the way it is?

Alternatives considered

1. Make main repo keep track of all shares.