Jim Nasby wrote:
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...
The trouble with running "cvs update" a second time is that it will be
just as liable to fail as the first run. S
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
Greg Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
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
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> 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 repo
> Unfortunately, this fell over first time out:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=200
6-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!
Are you running this from msys or fr
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>>> 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.
> So what I'm going to try instead is
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
Jim Nasby wrote:
yes, it's a file/directory it doesn't know about.
At one stage I suppressed these checks, but I found that too many
times we saw errors due to unclean repos. So now buildfarm insists
on having a clean repo.
I suppose I could provide a switch to turn it off ... in one
On Jun 2, 2006, at 10:27 AM, Andrew Dunstan wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What's happening here is that cvs actually creates the directory
and then later prunes it when it finds it is empty.
I find that explanation pretty unconvinci
Tom Lane wrote:
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 sinc
Andrew Dunstan <[EMAIL PROTECTED]> 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 r
Joshua D. Drake wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What's happening here is that cvs actually creates the directory and
then later prunes it when it finds it is empty.
I find that explanation pretty unconvincing. Why would cvs print a "?"
for such a directory?
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> What's happening here is that cvs actually creates the directory and
>>> then later prunes it when it finds it is empty.
>>
>> I find that explanation pretty unconvincing. Why would
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What's happening here is that cvs actually creates the directory and
then later prunes it when it finds it is empty.
I find that explanation pretty unconvincing. Why would cvs print a "?"
for such a directory?
cvs will print a ? if
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What's happening here is that cvs actually creates the directory and
then later prunes it when it finds it is empty.
I find that explanation pretty unconvincing. Why would cvs print a "?"
for such a directory?
A
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> What's happening here is that cvs actually creates the directory and
> then later prunes it when it finds it is empty.
I find that explanation pretty unconvincing. Why would cvs print a "?"
for such a directory?
regards, tom l
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I strongly suspect that snake is hitting the "file/directory doesn't
disappear immediately when you unlink/rmdir" problem on Windows that we have
had to code around inside Postgres. It looks like cvs is trying to prune an
empty dire
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I strongly suspect that snake is hitting the "file/directory doesn't
> disappear immediately when you unlink/rmdir" problem on Windows that we have
> had to code around inside Postgres. It looks like cvs is trying to prune an
> empty directory but isn'
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: 02 June 2006 12:18
> To: Dave Page
> Cc: [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] 'CVS-Unknown' buildfarm failures?
>
>
> That'
Dave Page said:
>> I have
>> repeatedly
>> advised buildfarm member owners not to build by hand in the
>> buildfarm repos.
>> Not everybody listens, apparently.
>
> The owner of snake can guarantee that that is not the case - that box
> is not used for *anything* other than the buildfarm and hasn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andrew Dunstan
> Sent: 02 June 2006 03:31
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 'CVS-Unknown' buildfarm failures
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Tom Lane said:
>> meerkat and snake both have persistent "CVS-Unknown" failures in some
>> but not all branches. I can't see any evidence of an actual failure in
>> their logs though.
> cvs-unknown means there are unknown files in the repo:
Oh. Wel
Joshua D. Drake said:
> Tom Lane wrote:
>>
>> A more radical answer is to have the script go ahead and delete the
>> offending files itself, but I can see where that might not have good
>> fail-soft behavior ...
>
> I have manually ran a dist-clean on meerkat for 8_0 and 8_1 and am
> rerunning the
Tom Lane said:
> meerkat and snake both have persistent "CVS-Unknown" failures in some
> but not all branches. I can't see any evidence of an actual failure in
> their logs though. What I do see is "?" entries about files that
> shouldn't be there --- for instance, meerkat apparently needs a "mak
Tom Lane wrote:
meerkat and snake both have persistent "CVS-Unknown" failures in some
but not all branches. I can't see any evidence of an actual failure
in their logs though. What I do see is "?" entries about files that
shouldn't be there --- for instance, meerkat apparently needs a "make
dis
meerkat and snake both have persistent "CVS-Unknown" failures in some
but not all branches. I can't see any evidence of an actual failure
in their logs though. What I do see is "?" entries about files that
shouldn't be there --- for instance, meerkat apparently needs a "make
distclean". If that'
26 matches
Mail list logo
