Re: 'CVS-Unknown' buildfarm failures?

From: Jim Nasby <jnasby(at)pervasive(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 'CVS-Unknown' buildfarm failures?
Date: 2006-06-05 13:19:59
Message-ID: A1FFDEFA-F84F-438C-874F-BB5B7E19494B@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jun 4, 2006, at 8:18 AM, Andrew Dunstan wrote:
> I said:
>
>>>
>>> Another option would be to re-run cvs up one more time if we get any
>>> unexpected files. It sounds like that would fix this issue on
>>> windows
>>> machines, while still ensuring we had a clean repo to work from.
>>>
>>
>> please see the new release of the buildfarm client, in which I have
>> followed Tom's suggestion of removing the -P flag from the
>> checkout and
>> update commands - that should solve the Windows problem, as it
>> will no
>> longer try to remove the directory. I hope that solves the problem -
>> if not I'll have a look at other solutions.
>>
>
> Unfortunately, this fell over first time out:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?
> nm=loris&dt=2006-06-04%2012:09:33
> The fix handled directories, but we got a false positive from a
> rename not
> being immediate either, it seems. Bloody Windows!
>
> One thought I had was to force Windows to use CVS export rather
> than update.
> This has 2 disadvantages: it requires a complete repo fetch every
> run, even
> if we don't need to do anything because nothing has changed, and it
> also
> means we can't report the version numbers on files changed. Example:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?
> nm=loris&dt=2006-06-04%2012:21:43
> So what I'm going to try instead is a variation on Jim's suggestion
> above,
> but instead of re-running cvs update, what we'll do is a longish
> sleep (say
> 10 or 20 secs) which should be enough time for Windows to get its act
> together, and then run cvs status, which will also show us
> extraneous files.

What about my suggestion of runing CVS a second time if we get
extraneous files the first go-round? I'm guessing there'd have to be
a sleep in there as well...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2006-06-05 13:29:56 Re: More thoughts about planner's cost estimates
Previous Message Jim Nasby 2006-06-05 13:14:31 Re: Faster Updates