[PATCH 12 of 14] vfs: add the possibility to have a "ward" to check vfs usage

[Yuya Nishihara]

On Thu, 06 Jul 2017 20:53:50 +0200, Boris Feld wrote:
> On Wed, 2017-07-05 at 23:55 +0900, Yuya Nishihara wrote:
> > On Sun, 02 Jul 2017 04:56:37 +0200, Pierre-Yves David wrote:
> > > # HG changeset patch
> > > # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
> > > # Date 1470323266 -7200
> > > #      Thu Aug 04 17:07:46 2016 +0200
> > > # Node ID ebf81efdd6d7ff15c64683933635616c00475688
> > > # Parent  34b8be7f0420b07d0f7b71379c6055e5b26223d5
> > > # EXP-Topic vfs.ward
> > > # Available At https://www.mercurial-scm.org/repo/users/marmoute/me
> > > rcurial/
> > > #              hg pull https://www.mercurial-scm.org/repo/users/mar
> > > moute/mercurial/ -r ebf81efdd6d7
> > > vfs: add the possibility to have a "ward" to check vfs usage
> > > The feature has some similarity with the 'pathauditor', but further
> > > digging
> > > show it make more sense to keep them separated. The path auditor is
> > > fairly
> > > autonomous (create from vfs.__init__ without any extra
> > > information), and check
> > > very generic details. On the other hand, the wards will have deeper
> > > knownledge
> > > of the Mercurial logic and is created at the local repository
> > > level. Mixing the
> > > two would add much complexity for no real gains.
> > 
> > My gut feeling is that vfs isn't the right place if they require
> > deeper
> > knowledge of repository/dirstate logic. And the whole weakref
> > business
> > floating around wards, hooks and transaction seems like just getting
> > around
> > layering violation.
> 
> We pondered on this choice a long time and couldn't find any other
> layer that is used by both Mercurial core and the extensions to access
> the file system. It seems to be the highest abstraction layer we could
> hook into without introducing a new one and updating all callers.
> 
> Our reflexion is, as the vfs classes comes from the scmutil file, it
> seems okay to have scm related logic in that layer.

IIRC, one possible alternative was to move lock itself to a vfs as the
whole vfs is theoretically covered by the lock.

BTW, the ward itself doesn't require deeper knowledge of repo object right
now. Neither does the auditor. How will the ward API be evolved to depend
on repository-level data?

> > Do you have any idea how to expand this ward() callback to the other
> > vfs
> > operations, which have different set of parameters?
> 
> All other operations (move, delete, copy, etc) could be "translated" to
> 'read' or 'write' mode. An alternative would be to abstract the mode
> with a couple of symbolic constant "create, update, append, delete, …".
> What do you think?

So it will be quite similar to audit(path) if it had a mode flag?