Re: manage concurrent development (was: email settings for sending mail on checkin of files, )

[Aaron Bono]

Honestly, I would set up a cron job that runs every X minutes and does a compare, creates a summary of the changes and sends an email to the group if there are any.  Then it does an update on the changes it has notified the group about.  You would have significant control over how the data is summarized, how many emails are sent out and can even store the summaries in a database for better searching and monitoring.  Of course, this would force you to write your own application that monitors CVS rather than using something already written, tested and otherwise perfected.

If your repository is highly active, email notifications could be a burden.  But I do see how notification is nice if you are waiting on a change from someone else.  Keeps you from having to constantly check for updates and simplifies communication between team members.

-Aaron Bono

On 6/22/06, address@hidden <address@hidden > wrote:

Aaron Bono wrote:
> May I ask what you are doing with this email?  I can't think of a
> reason to myself and am very interested in new and innovative ways
> people manage concurrent development.

Well, I just configured "loginfo" to this effect and I find it useful to
have CVS mail a message to certain developers when a new revision of a
file is committed.

I think it gives a nice overview of who commits what. Running a nifty
mail reader you can also do all kind of interesting search queries (for
users, files, commit message,...). It's also a kind of active (push)
service e.g. when someone is waiting for a certain fix to be commited.

What I don't like about "loginfo" is that it does not group commit
emails but sends one per directory.

I like to know what alternatives exist that help to keep an eye on
commits and how to track grouped changes. What do you recommend?
Something like Mozilla's Tinderbox?

Cheers
Daniel Kabs