From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16844 invoked by alias); 18 Aug 2003 09:04:47 -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 16836 invoked from network); 18 Aug 2003 09:04:46 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 18 Aug 2003 09:04:46 -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 h7I94iQH012437; Mon, 18 Aug 2003 04:04:44 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h7I94iHK029388; Mon, 18 Aug 2003 04:04:44 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h7I94i9W029387; Mon, 18 Aug 2003 05:04:44 -0400 Date: Mon, 18 Aug 2003 09:04:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200308180904.h7I94i9W029387@duracef.shout.net> To: gdb@sources.redhat.com, xyzzy@hotpop.com Subject: Re: binutils+gdb CVS module X-SW-Source: 2003-08/txt/msg00185.txt.bz2 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". 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). That's issue as I understand it. If someone who knows more wants to correct me, just jump in. Michael C