RE: Cannot build latest CVS setup

["Dave Korn" <dave dot korn at artimi dot com>]

----Original Message----
>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
>>> [snip]
>>> dk@mace /usr/build/apps/setup> cvs update -dP
>>> [snip]
>>> 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
> subdirectory). 

  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
> repository.  

  Well, that could explain it; I have had that tree lying around for quite a
while now.

  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'.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....