"Stephen J. Turnbull" <stephen@xemacs.org> writes:
Mark Hammond writes:
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Possibly - although I would expect the existing section names be reused when applied to a versioned file, I'd be more than happy for the hg guys to declare new names are appropriate for this.
If there's already an [Encode] section, that's different. (I don't details, I'm not that big a Mercurial fan.) But you'd still need a way to differentiate win32text rules from other encoding rules.
There is a [decode] and an [encode] section: http://www.selenic.com/mercurial/hgrc.5.html#decode-encode The win32text extension works by defining new filters which can then be used like this: [encode] ** = cleverencode: [decode] ** = cleverdecode: (they are "clever" because they skip binary files)
True, but how many people will just download the extension and enable it?
In the ideal world, exactly as many people who would read the Python developer guide, then download and install the extension based purely on that. IOW, it is Python itself setting the policy, so people need to make their own decisions based on that, regardless of whether the tool enforces it or not.
You're missing the point. I'm not talking about whether it will work for Python, I'm talking about the worry that somebody will post a way cool Python branch and require a private extension, which everybody will just automatically install and enable, which extension then proceeds to phone home to Spammer Haven, Inc. with the contents of your email contact list. That's what I mean by "social engineering," and why I worry about policy pushback from Mercurial HQ.
Maybe that's more paranoid than they are.... But it can't hurt your cause to be ready for that kind of worry.
Oh, we try to be very paranoid in Mercurial :-) That's why you don't see any support for copying hgrc files when you clone and why hg wont trust hgrc files not owned by you: it should be safe to do cd ~collegue/src/python hg tip -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.