|
⇤ ← Revision 1 as of 2018-10-12 10:09:02
Size: 2836
Comment:
|
← Revision 2 as of 2018-12-19 18:28:01 ⇥
Size: 2058
Comment: We no longer plan to transparently update the working copy
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 17: | Line 17: |
| Keep track of narrowspec separately for store and working copy. Detect when there's a mismatch and update the working copy and the dirstate. 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 (other than to find how to update the dirstate when the store's narrowspec changed). | 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. |
| Line 25: | Line 25: |
| The update of working copy and dirstate 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? === Locking === We already update the dirstate any time context.status() is called if any files are found to have become clean. That update is done only if the working directory lock can be acquired without waiting. We'll do the same thing if the narrowspec is found to have changed: we update only if the working directory lock can be acquired without waiting. If the dirstate and the working copy is *not* updated, it should still mostly work fine (we respect the store's narrowspec). However, if narrowing is done by one share *while* another one is reading from it, we may get a crash. This is similar to how stripping in on share can break reads from another (I assume). We also already crash if you narrow while another command is running in a single repo. |
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? |
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.
- Would require locking N working directories. - A share may even be on a different FS than the main repo.