From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5224 invoked by alias); 18 Aug 2003 10:09:54 -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 5217 invoked from network); 18 Aug 2003 10:09:52 -0000 Received: from unknown (HELO steve.softier.local) (62.90.245.250) by sources.redhat.com with SMTP; 18 Aug 2003 10:09:52 -0000 Received: from steve.softier.local (localhost.localdomain [127.0.0.1]) by steve.softier.local (8.12.8/8.12.8) with ESMTP id h7IA9mkW005323 for ; Mon, 18 Aug 2003 13:09:49 +0300 Received: (from steve@localhost) by steve.softier.local (8.12.8/8.12.8/Submit) id h7IA9ljb005321; Mon, 18 Aug 2003 13:09:47 +0300 X-Authentication-Warning: steve.softier.local: steve set sender to xyzzy@hotpop.com using -f Subject: Re: binutils+gdb CVS module From: Stephen Biggs To: GDB list In-Reply-To: <200308180904.h7I94i9W029387@duracef.shout.net> References: <200308180904.h7I94i9W029387@duracef.shout.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 Aug 2003 10:09:00 -0000 Message-Id: <1061201387.10548.76.camel@steve.softier.local> Mime-Version: 1.0 X-SW-Source: 2003-08/txt/msg00186.txt.bz2 Hi Michael, On Mon, 2003-08-18 at 12:04, Michael Elizabeth Chastain wrote: > Hi Stephen, > > > (is this the same as gdb+binutils??) > > Yes, gdb+binutils and binutils+gdb are identical. > You can check out 'modules' and look in the modules list if you like. > > > Yesterday, after the update, there were the directories libgloss, sid, > > tcl, and quite a few others which messed up my build because the target > > I am trying to develop has no idea about these things. > > Sounds like you did "cvs update -d" instead of "cvs update". Yes, exactly. > > This is a known deficiency with cvs. When you do the initial checkout > of binutils+gdb, you get only the files and directories that are part > of this module. But the name "binutils+gdb" is not recorded anywhere. > > When you do "cvs update", your cvs client program doesn't know about > "binutils+gdb" any more. It knows that you have a restricted subset of > the files and dirs from the server, but it doesn't know *which* subset. > So ... for all the files and dirs on the server which you *don't* > already have ... "cvs update" doesn't know whether you need them for > the module you checked out, because "cvs checkout" did not record the > name of the module that it checked out. > > So there are two modes, both a little deficient. In the plain "cvs > update" mode, cvs will update the top-level files and dirs that you > already have, but it won't create any new ones. This correctly handles > all the files and dirs on the server that you don't want to see, like > libgloss, sid, and tcl. But if someone actually DOES create a new file > at the top level, and the new file really IS part of binutils+gdb, cvs > won't fetch it. > > In the "cvs update -d" mode, cvs will update everything, including > creating new files. That's probably what happened to your work area. > Hundreds of megabytes of extra stuff show up, and your build breaks. > On the plus side, if someone created a new top-level file that you > needed, you did get it. > > The normal workaround is to do "cvs update" almost all of the time, with > no "-d", and to handle new top-level files and directories specially. > Fortunately they don't appear very often (a few times a year). How does one know when there is something new? Add a watch via email? Is that even allowed with this repository? > > That's issue as I understand it. If someone who knows more wants to > correct me, just jump in. > Thanks very much for the concise and informative reply. > Michael C >