Encouraging best practices through server communication

[Steve Barnes]

On 10/12/13 15:27, Augie Fackler wrote:
> On Tue, Dec 10, 2013 at 07:41:50PM +0900, Gregory Szorc wrote:
>
> [snip wall of text]
>
>> While the extension isn't finished and has yet to be deployed outside of
>> testing, I thought I'd share it with this list for a few reasons. First, I
>> think people may find it interesting. Second, I have technical
>> concerns/questions about the implementation. There are a number of aspects
>> of the implementation that feel too hacky to me. There is also functionality
>> not possible with Mercurial today (mainly due to the wire protocol design).
>> I'd like to have a discussion about supporting these use cases in a future
>> Mercurial release. Notably:
>>
>> * Client doesn't self-advertise capabilities like servers do. It would be
>> cool if servers could proactively sniff for missing capabilities and be like
>> "upgrade your Mercurial install!"
>>
>> * Passing messages for user display from server to client is not well
>> supported. Only some commands have their output sent to the client. I would
>> like a dedicated "band" in the protocol for transporting messages back to
>> clients for *any* command. I think allowing servers to "advertise" message
>> of the day or such on pull could be very useful.
> Yeah. Right now I think this only works for push, which is a slight
> bummer. Not sure how fixable this is though.
>
>> * Possibly a superset of the above - it's not possible to exchange arbitrary
>> metadata as part of client-server communication. My extension would be much,
>> much easier if every command request and response could have arbitrary
>> (key-value?) metadata attached to it.
> pushkey lets you do this for an extension
>
>> Is there any interesting in pursuing these features? Do people think my
>> extension has wheels?
> I think this is actually a great idea - it'd offer a way for large
> projects and companies to enforce (at some level) use of some
> extensions. I've been thinking about this a little on my own, but the
> idea of an extension and pushkey (or similar) hadn't occurred to me as
> a way to detect this.
>
> Might be worth putting together a wiki page to sketch out a more
> detailed plan and talking on -devel about it. I'd definitely be interested.
>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=941856
>>
>> Gregory Szorc
>> gregory.szorc at gmail.com
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>
Can I suggest a way of enforcing a plug-in is present, has a given 
version, etc., policy by simply having the relevant plug-ins 'sign' 
repository operations and having a server side pre-/(any change to the 
repository)/ hooks that checks for the signature(s).  Hooks that fail 
can send a text message for reason for fail allowing the "You need to 
install/upgrade/enable plug-in XXXX!".  While this signature would be a 
part of the commit message it could be stripped out of the record or 
hidden and would not require rework of the protocol.

It would also be possible to have a 'Repo Message of the Day/Week' by 
having a branch for them and a plug-in that displays them if they 
haven't been shown yet.  Since branches are downloaded/updated even if 
you are not on them this should work nicely and means that announcements 
become a part of the project history.

Just by 2 pence - BTW I like the basic idea.

Gadget/Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20131210/7343f4ab/attachment-0002.html>