From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13204 invoked by alias); 18 Aug 2003 10:34:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13195 invoked from network); 18 Aug 2003 10:34:40 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 18 Aug 2003 10:34:40 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.9/8.12.9) with ESMTP id h7IAYdQH019302; Mon, 18 Aug 2003 05:34:39 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h7IAYdHK031303; Mon, 18 Aug 2003 05:34:39 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h7IAYdbE031302; Mon, 18 Aug 2003 06:34:39 -0400 Date: Mon, 18 Aug 2003 10:34:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200308181034.h7IAYdbE031302@duracef.shout.net> To: gdb@sources.redhat.com, xyzzy@hotpop.com Subject: Re: binutils+gdb CVS module X-SW-Source: 2003-08/txt/msg00187.txt.bz2 Hi Stephen, > How does one know when there is something new? Add a watch via email? > Is that even allowed with this repository? Watches are a big dead end as far I can tell. They only work on files, not on directories, and they require other people to do 'cvs edit' to send the signal. Anyways, gdb doesn't use them. The usual procedure is to subscribe to gdb-cvs mailing list and watch the commits go by. Also, if your work area starts mysteriously failing, look in the gdb mailing list and see if people are talking about another round of top level changes. AFAIK, the most recent new file was src-release on 2002-10-01. So 'cvs update' will fail about once a year. Less, really, for an ordinary gdb developer who is not making releases or editing the configuration machinery (editing Makefile.tpl and stuff). Me, I just do fresh "cvs checkout" a lot. But I do more testing than developing. Michael C