From: Stephen Biggs <xyzzy@hotpop.com>
To: GDB list <gdb@sources.redhat.com>
Subject: Re: binutils+gdb CVS module
Date: Mon, 18 Aug 2003 10:09:00 -0000 [thread overview]
Message-ID: <1061201387.10548.76.camel@steve.softier.local> (raw)
In-Reply-To: <200308180904.h7I94i9W029387@duracef.shout.net>
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
>
next prev parent reply other threads:[~2003-08-18 10:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-18 9:04 Michael Elizabeth Chastain
2003-08-18 10:09 ` Stephen Biggs [this message]
2003-08-18 12:56 ` Daniel Jacobowitz
2003-08-18 13:03 ` Bob Rossi
2003-08-18 14:51 ` Stephen Biggs
2003-08-18 14:54 ` Daniel Jacobowitz
2003-08-18 15:10 ` Stephen Biggs
-- strict thread matches above, loose matches on Subject: below --
2003-08-18 10:34 Michael Elizabeth Chastain
2003-08-18 8:10 Stephen Biggs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1061201387.10548.76.camel@steve.softier.local \
--to=xyzzy@hotpop.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).