[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Notifications
Re: CVS Notifications
Tue, 30 Aug 2005 10:15:45 -0400
Mozilla Thunderbird 1.0.6 (Windows/20050716)
If all you want is commit notifications and not advisory locking, I
suggest you use hang the commit_prep.pl and log.pl scripts (distributed
with CVS in the contrib directory) from the commitinfo and loginfo
triggers, respectively. This allows you to change the subject of the
emails and even configure the emails to contain diffs of the changes.
Also, please read the manual on configuring different triggers per
S I wrote:
> Thank you.
> One last question: If in my CVS root I have 3 existing projects
> unrelated to each other; does that mean turning on notifications,
> developers from the 3 different proj/modules are going to get all the
> updates whether they want to or not?
> ----Original Message Follows----
> From: Paul Van Delst <address@hidden>
> To: S I <address@hidden>
> Subject: Re: CVS Notifications
> Date: Thu, 18 Aug 2005 16:38:13 -0400
> MIME-Version: 1.0
> Received: from mocbox2.nems.noaa.gov ([220.127.116.11]) by
> mc5-f22.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug
> 2005 13:38:19 -0700
> Received: from [18.104.22.168] ([22.214.171.124]) by
> mocbox2.nems.noaa.gov (Netscape Messaging Server 4.15) with
> ESMTP id ILFQNU00.0JT for <address@hidden>; Thu, 18 Aug
> 2005 16:38:18 -0400
> X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
> Organization: address@hidden/NCEP/EMC
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10)
> Gecko/20050719 Red Hat/1.7.10-126.96.36.199
> X-Accept-Language: en-us, en
> References: <address@hidden>
> Return-Path: address@hidden
> X-OriginalArrivalTime: 18 Aug 2005 20:38:19.0885 (UTC)
> S I wrote:
>> Thank you Paul for your response.
>> I executed "cvs watch on" at the root of the project and now I'm
>> receiving emails. I'm the only one on the email list. I have couple
>> of questions:
>> 1. Does cvs watch on, on my PC cause any problems for the users? In
>> other words, will it force them to do cvs edit or prevent them from
>> their regular activities? I just don't want to interrupt anyone and
>> don't like any unforseen consequences. I want to be the only one
>> receiving emails w/o messing up anyone else.
> My copy of the manual tells me that a "cvs watch add" does *not*
> require a "cvs watch on" for you to be notified, but that it is a good
> idea. I guess it depends on how curmudgeonly your developers are when
> they discover they need to do a "cvs edit" before editing a file. As
> the docs states, CVS does not enforce the required behaviour.
>> 2. Could I turn on notifications per trunk or branch SELECTIVELY?
>> Yesterday, I turned it on under my checked out branch (sticky tags)
>> but I think it does not work that way and I'm getting commit emails
>> on anything they committed regardless where in the module or
>> project. I'm not finding any literature on this.
> I don't think so. There is no mention of trunk or branch specific
> switches to the watch command - it only operates on files. This might
> be a question better asked in the group, though, to let the experts
> mull it over.
>> 3. So you're saying if the developers choose to participate or
>> collaborate, they have to do their own cvs watch on or edit per user?
> That has been my experience. Even if *you* do a "cvs watch add" for
> the entire repository tree, this only affects you as the user that did
> it. With a group of developers, this can be a good thing and a bad
> thing. If different groups/people were working on totally independent
> parts of a code repository, they probably couldn't care less that Joe
> Bloggs checked out code from a repository module with which they have
> nothing to do - in fact the notification emails may become annoying to
> the point where they disable *all* watches. On the other hand,
> *within* one of these development groups, it would be prudent for them
> to add themselves to the appropriate watch lists to save them the
> heartache of resolving conflicts later on when several of them were
> editing the same file at the same time without knowing it.
> In the end, the users will do whatever they want so maybe the best you
> can do is let them know about the feature and why it behooves them to
> use it.
> Paul van Delst
> CIMSS @ NOAA/NCEP/EMC
> Info-cvs mailing list
Derek R. Price
CVS Solutions Architect
v: +1 717.579.6168
f: +1 717.234.3125