hgext/narrow/TODO.rst
author Gregory Szorc <gregory.szorc@gmail.com>
Tue, 18 Sep 2018 15:32:11 -0700
changeset 39787 a063786c89fb
parent 39561 10a8472f6662
child 40079 937ce75ea18c
permissions -rw-r--r--
narrow: remove narrowrevlog Core now automatically enables ellipsis support on revlogs when repositories have narrow enabled. So, we no longer need to globally register the revlog flag as part of activating the narrow extension and this code can be deleted. A side effect of this change is that repositories will now raise an error on encountering an ellipsis flag when the narrow extension is loaded. Previously, loading the narrow extension on a non-narrow repo could result in silent usage of the ellipsis flag. This could lead to undetected bugs. I think the new behavior is more correct. Differential Revision: https://phab.mercurial-scm.org/D4649

Integration with the share extension needs improvement. Right now
we've seen some odd bugs, and the way we modify the contents of the
.hg/shared file is unfortunate. See wrappostshare() and unsharenarrowspec().

Resolve commentary on narrowrepo.wraprepo.narrowrepository.status
about the filtering of status being done at an awkward layer. This
came up the import to hgext, but nobody's got concrete improvement
ideas as of then.

Address commentary in manifest.excludedmanifestrevlog.add -
specifically we should improve the collaboration with core so that
add() never gets called on an excluded directory and we can improve
the stand-in to raise a ProgrammingError.

Reason more completely about rename-filtering logic in
narrowfilelog. There could be some surprises lurking there.

Formally document the narrowspec format. Unify with sparse, if at all
possible. For bonus points, unify with the server-specified narrowspec
format.

narrowrepo.setnarrowpats() or narrowspec.save() need to make sure
they're holding the wlock.