Mark Hammond writes:
* Add support for versioned 'filter rules' - eg, /.hgfilters or similar.
* This might be pushing my luck, but: add 'defensive' support to core hg for this feature - if /.hgfilters exists, hg should refuse to operate on the working tree unless the win32text extension is enabled.
The name ".hgfilters" should be changed, then. That's way too generic to be used to "enforce" something as specific as win32text. I can imagine all kinds of things wanting to use rules or filters. How about a scheme where an extension reserves a filter file for itself in .hgfilters? In this case the win32text filters would live in .hgfilters/win32text, and if that file exists hg checks that the corresponding extension has been enabled, and if not, refuses to run (and tells you that if you really want to override, you rename the file to win32text.disabled and commit). Note that Bazaar is currently discussing some similar policies. I think the name they have settled on is ".bzrrules". Maybe .hgrules is a better name. -- ________________________________________________________________________ ________________________________________________________________________ Q: What are those straight lines? A: "XEmacs rules."