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
>>> 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:
> 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
> means we can't report the version numbers on files changed. Example:
> So what I'm going to try instead is a variation on Jim's suggestion
> 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
pgsql-hackers by date
|Next:||From: Jim Nasby||Date: 2006-06-05 13:29:56|
|Subject: Re: More thoughts about planner's cost estimates |
|Previous:||From: Jim Nasby||Date: 2006-06-05 13:14:31|
|Subject: Re: Faster Updates |