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
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. So
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
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 a variation
Unfortunately, this fell over first time out:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lorisdt=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 from
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 report the
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
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
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
-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?
cvs-unknown means there are unknown
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't even
-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's why I said almost always :-)
:-)
I strongly suspect
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't fast
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 directory
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 lane
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?
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 it
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 cvs print a ?
for
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?
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
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
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
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 make
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. Well, it needs
24 matches
Mail list logo
