Skip site navigation (1) Skip section navigation (2)

Re: 'CVS-Unknown' buildfarm failures?

From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: 'CVS-Unknown' buildfarm failures?
Date: 2006-06-02 02:31:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane said:
> meerkat and snake both have persistent "CVS-Unknown" failures in some
> but not all branches.  I can't see any evidence of an actual failure in
> their logs though.  What I do see is "?" entries about files that
> shouldn't be there --- for instance, meerkat apparently needs a "make
> distclean".  If that's what's causing the failure report, could we get
> the buildfarm to show a more useful status message?  I'd always assumed
> that "CVS-Unknown" suggested a transient problem such as
> connection loss, and there wasn't any need for human intervention.
> A more radical answer is to have the script go ahead and delete the
> offending files itself, but I can see where that might not have good
> fail-soft behavior ...

cvs-unknown means there are unknown files in the repo:

   my $unknown_files = grep {/^\?/ } @cvslog;
     if ($unknown_files);

This is almost always a case of operator error. buildfarm only ever builds
in a copy of the repo, not in the permanent repo itself, so there should
NEVER be any file there which does not come from CVS. I have repeatedly
advised buildfarm member owners not to build by hand in the buildfarm repos.
 Not everybody listens, apparently.

All this is intended to ensure that we are actually working on a faithful
reflection of the repo, and not something that has been
mangled somehow.

I can call it "CVS-Unknown-Files" if that will make it clearer.



In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-06-02 02:32:10
Subject: Re: More thoughts about planner's cost estimates
Previous:From: Tom LaneDate: 2006-06-02 02:27:39
Subject: Re: [PATCH] Magic block for modules

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group