Re: Build failure of trunk on i686-pc-gnu-linux

[Thomas Schwinge <tschwinge at gnu dot org>]

Hello!

On Mon, Nov 19, 2007 at 05:22:52PM -0800, Andrew Pinski wrote:
> On 11/19/07, Thomas Schwinge <tschwinge@gnu.org> wrote:
> > I'm glad that nobody answered.  I've been doing nothing wrong.  And also
> > it's not someone else's fault.  But let me tell you what in fact was
> > going wrong.
> 
> I think the reason why nobody answered is because we are all busy
> doing real work.

Now I'm not sure about how to take that one.  I for sure didn't mean to
blame or even insult someone of you GCC people.  But then, why do you now
in turn think I wasn't trying to get ``real work'' done?


> > I had a some-months-old checkout of GCC trunk on my disk.  Now I needed
> > such a checkout and thought: ``Good that the old one -- which I only used
> > once for compiling and didn't do any modifications to it -- is still
> > laying around: I'll simply use that one after having ran a ``svn update''
> > in there.''  I also ran a ``svn diff''.  No modifications shown.  Also, I
> > attempted a ``svn status'', but as that one -- apart from completely
> > saturating the system's disk I/O (Pentium M with 1.7 GHz, 768 MiB of RAM)
> > -- didn't give any output after having it had running for half a minute,
> > I terminated it again.  After all, both ``svn update'' and ``svn diff''
> > had made me think that the tree was as clean as it could be.  (SVN was
> > made for easy transition from CVS, right?)
> 
> I use svn stat all the time without any issues.  It does take over a
> half a minute for some of my local trees (they are not FSF GCC checks
> and include a lot more files) but it is reasonable.

On a freshly booted, otherwise idle system:

#v+
$ time svn status
M      libgcc/config.host
M      gcc/config.gcc
M      gcc/unwind-generic.h
M      gcc/config/i386/gnu.h
M      gcc/config/gnu.h

real    2m17.461s
user    0m2.972s
sys     0m2.736s
#v-

Subsequent runs, as long as the data is still being cached, are much
faster, of course.

> What version of svn are you using?  It might be something which is
> already fixed in a newer version of svn.

This is what Ubuntu feisty ships, which is version 1.4.3 (r23084), Ubuntu
package version 1.4.3dfsg1-1ubuntu1.2.


Regards,
 Thomas

Attachment: signature.asc
Description: Digital signature