This is an archive of the discontinued Mercurial Phabricator instance.

narrow: detect if narrowspec was changed in a different share
ClosedPublic

Authored by martinvonz on Nov 14 2018, 8:12 PM.

Details

Summary

With this commit, hg share should be usable with narrow
repos. Design explained on
https://www.mercurial-scm.org/wiki/NarrowSharePlan

I was running into cache invalidation problems when updating the
narrowspec. After spending a day trying to figure out a good solution,
I resorted to just assigning repo.narrowpats and repo._narrowmatch
after invalidating them.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

martinvonz created this revision.Nov 14 2018, 8:12 PM
yuja added a subscriber: yuja.Nov 17 2018, 2:25 AM
  1. d1/f, d3/f, d3/g and d5/f should no longer be reported $ hg -R main files

+ not deleting possibly dirty file d3/f
+ not deleting possibly dirty file d3/g
+ not deleting possibly dirty file d5/f

I don't think it's good idea that any read-only commands can update working-copy
files. And I suspect the narrowing/widening process could get complicated if
merge/rebase were underway.

Instead, can't we take the repository as dirty/unfinished state if local
narrowspec differs from store's? The user will have to run some command to
narrow/widen the working directory. Maybe he can also restore narrowspec of
the store to finish ongoing merge/rebase.

In D5278#78697, @yuja wrote:
  1. d1/f, d3/f, d3/g and d5/f should no longer be reported $ hg -R main files

+ not deleting possibly dirty file d3/f
+ not deleting possibly dirty file d3/g
+ not deleting possibly dirty file d5/f

I don't think it's good idea that any read-only commands can update working-copy
files. And I suspect the narrowing/widening process could get complicated if
merge/rebase were underway.
Instead, can't we take the repository as dirty/unfinished state if local
narrowspec differs from store's? The user will have to run some command to
narrow/widen the working directory. Maybe he can also restore narrowspec of
the store to finish ongoing merge/rebase.

That's reasonable. I'll make this instead abort if the narrowspecs don't match and I'll add a hg tracked --update-working-copy or something like that.

martinvonz edited the summary of this revision. (Show Details)Dec 21 2018, 2:50 AM
martinvonz updated this revision to Diff 12940.

This is ready for review again, thanks

martinvonz updated this revision to Diff 12944.Dec 21 2018, 1:11 PM
martinvonz updated this revision to Diff 12945.Dec 21 2018, 1:14 PM
yuja added a comment.Dec 22 2018, 2:17 AM
This is ready for review again, thanks

Can you somehow serialize the stack? hg phabread :D5278 doesn't work, and
I can't figure out which patches are still alive.

I think it was just D5472 that conflicted, so it might work now that that's
queued. This patch should go last of my pending patches. If it's still not
working, I'll try to fix it when I'm back in a week or two.

This revision was automatically updated to reflect the committed changes.
yuja added a comment.Dec 22 2018, 9:23 PM

Queued, thanks.

+def copytoworkingcopy(repo, tr):
+ if tr:
+ def write(file):
+ spec = repo.svfs.read(FILENAME)
+ file.write(spec)
+ file.close()
+ tr.addfilegenerator('narrowspec', (DIRSTATE_FILENAME,), write,
+ location='plain')
+ else:
+ spec = repo.svfs.read(FILENAME)
+ repo.vfs.write(DIRSTATE_FILENAME, spec)

Maybe write(..., atomictemp=True) is a safer option.

+def _writeaddedfiles(repo, pctx, files):
+ actions = merge.emptyactions()
+ addgaction = actions['g'].append

Nit: merge.ACTION_GET.