This is the mail archive of the
mailing list for the Cygwin project.
RE: Cannot build latest CVS setup
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin-apps at cygwin dot com>
- Date: Wed, 25 May 2005 13:52:38 +0100
- Subject: RE: Cannot build latest CVS setup
>From: Igor Pechtchanski
>Sent: 25 May 2005 13:38
> On Wed, 25 May 2005, Max Bowsher wrote:
>> Dave Korn wrote:
>>> Nope, really, it does, let me demonstrate:
>>> dk@mace /usr/build/apps/setup> cvs update
>>> dk@mace /usr/build/apps/setup> cvs update -dP
>>> cvs update: move away cfgaux/.direxists; it is in the way C
>>> cfgaux/.direxists dk@mace /usr/build/apps/setup>
>> The above works without errors for me!
> Ditto. FWIW,
> $ cat ~/.cvsrc
> cvs -r -q
> diff -upN
> update -d -P -I bootstrap.log
> checkout -P
> You probably have the same problem I did earlier, in that CVS doesn't have
> an entry for cfgaux (or, alternatively, that cfgaux doesn't have a CVS
I just tried with a fresh checkout and indeed it doesn't happen any more.
Both cfgaux dirs have a CVS subdir; the only difference is that my original
toplevel CVC/Entries doesn't list cfgaux and the new one does.
> I suspect this may've happened when I re-autotooled the
Well, that could explain it; I have had that tree lying around for quite a
Hmm, is it possible I did a "cvs update -dP" at a time before .direxists
was added, cvs tried to remove the dir - somewhat bogusly, because it still
had the symlinks in it - and removed it from the CVS/Entries file at that
time? Then after .direxists was added, "cvs update -dP" would indeed find
an unknown cfgaux dir in the way when it wanted to put it in. That would
certainly be a more reassuring explanation than the idea that CVS just loses
entries in the metadata for no apparent reason at all.
>If you run "cvs update" without -d, it simply won't expose
> the problem.
Yeh. It isn't really even a 'problem'.
Can't think of a witty .sigline today....