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

Re: 'CVS-Unknown' buildfarm failures?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, dpage(at)vale-housing(dot)co(dot)uk, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 'CVS-Unknown' buildfarm failures?
Date: 2006-06-02 15:57:45
Message-ID: 5556.1149263865@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I suppose I could provide a switch to turn it off ... in one recent case 
> the repo was genuinely not clean, though, so I am not terribly keen on 
> that approach - but I am open to persuasion.

No, I agree it's a good check.  Just wondering if we can reduce the
number of false positives.  The recent meerkat failures, for instance,
were *not* false positives.

Looking at the snake failures of this type on HEAD, I do see that the 
complaints are all about subdirectories that should have been pruned,
which makes Andrew's theory seem plausible.  Maybe we should file this
behavior as a cvs bug.

Sudden thought: is there any particularly good reason to use the cvs
update -P switch in buildfarm repositories?  If we simply eliminated
the create/prune thrashing for these directories, it'd fix the problem,
if Andrew's idea is correct.  Probably save a few cycles too.  And since
people are really not supposed to be using these checkouts for anything
else, they don't need to be pretty.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2006-06-02 16:11:06
Subject: Re: 'CVS-Unknown' buildfarm failures?
Previous:From: Andrew DunstanDate: 2006-06-02 15:27:13
Subject: Re: 'CVS-Unknown' buildfarm failures?

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