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@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461