On Fri, Apr 23, 2010 at 06:53, Stefan Küng <tortoise...@gmail.com> wrote: > On 23.04.2010 00:06, Hyrum K. Wright wrote: >> >> With the increased integration of build tools and other notification >> systems >> which desire knowledge of commit activity, it would be useful to provide >> an >> easier mechanism of installing post-commit notification, without having to >> use the hook infrastructure. Imagine a user being able to set up commit >> mails, CIA notifications, and buildbot notifications *without* having to >> have access to the repository. To that end, I propose the following. >> >> Simply a versioned property, which, when encountered during the course of >> a >> commit, causes the server to emit a notification. This property would be >> a >> list of URLs, to which the repository would send a specially formatted >> POST >> with the information about the commit. (The idea being that a committer >> to >> the project could set up this property, as well as the server which >> receives >> these notifications, all without the intervention of the repository >> administrator.) As part of the bubble up, the repo would queue these >> URLs, >> and then POST to them during the post-commit phase of the commit. >> >> Thoughts? > > We have something similar in TortoiseSVN: client-side hook scripts. > Some people use those to send out notifications after a commit, some to copy > files to their webserver, ... > http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-hooks > > But TortoiseSVN gathers all information purely on the client side. So I'm > not sure if this feature in svn would require a server-side change or hook > script to do that?
If the committers use various clients, then yes: some kind of server-side solution would be needed. Cheers, -g
