Re: Programming a Watcher File

I'm looking at the SVN:Notify, and it appears to require sendmail. Is
that correct? I would rather use NET::SMTP which is more platform
neutral.

What does the NET::SMTP notification look like? Does it do a diff
between files? Does it tell you all the files modified, or just the
ones you're interested in?

I'll try to separate out the notification system and make it optional.
That's actually a nice idea. The question is how do I pass the
notification stuff. I can't use STDOUT because Subversion captures
that.

On Tue, Mar 9, 2010 at 5:42 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Tue, Mar 9, 2010 at 1:15 AM, David Weintraub <qazwart_at_gmail.com> wrote:
>> The idea is to allow users to specify exactly which they want to
>> watch. It might be a few configuration files, images, etc.
>>
>> Hudson will notify if any files in the entire project are changed, and
>> when you do a dozen builds each day, the developers start to ignore
>> these build notices.
>>
>> This is something that most other version control systems allow and is
>> usually built in. Third party clients like SVN Notifier and Commit
>> Notifier is that they must be user installed and running on the user's
>> machine. If you aren't on that machine, you don't get notified.
>>
>> Something like Fisheye is good because that allows users to set
>> notifications and is not dependent upon the user's own system.
>> However, we don't have Fisheye.
>>
>> Subversion comes with a post-commit notification script written in
>> Perl, but this script requires a configuration file that sits on the
>> server. That means developers have to ask the administrator to set and
>> change notifications.  By putting the notification configurations
>> inside the repository, I allow users to set their own notifications.
>> Since it is the server that's running it, the notifications aren't
>> machine dependent.
>
> I think it's great functionality that you're building here. I for one
> would be quite interested in something like this, so if you could
> share it, that would be super (maybe even put it in "contrib" if it's
> ready?). Having developers manage their own notifications (all within
> the repos, and cross-platform, independent of client machine),
> specifying which files/paths they are interested in, is very useful
> functionality.
>
> Just a thought: it would be nice if you could make the coupling with
> the actual notification system a "loose coupling". To separate "how to
> determine who is notified" (what you're building now) from the
> "mechanism that sends the notifications". I'm currently using
> commit-email.pl, but am also looking at mailer.py (once we upgrade our
> server, including python bindings) and SVN::Notify
> (http://search.cpan.org/dist/SVN-Notify/). It would be nice to still
> be able to choose whichever notification system works best ...
>
> Johan
>

-- 
David Weintraub
qazwart_at_gmail.com