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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-06-02 16:11:06 | Re: 'CVS-Unknown' buildfarm failures? |
Previous Message | Andrew Dunstan | 2006-06-02 15:27:13 | Re: 'CVS-Unknown' buildfarm failures? |