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

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: (view raw, whole thread or download thread mbox)
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:
> 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:
> 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    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to


pgsql-hackers by date

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

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