Re: Nees help, some files checkout as empty

[Todd Denniston]

Dave Allaby wrote, On 01/31/2008 10:19 AM:
> Hello there CVS folks.
>
>  
>
> We have a rather glitchy problem that I'm having trouble understanding
> and could use some aid.
>
>  
>
> Often we will perform a cvs co using a module alias which checks out
> several modules together.  We have one module which only checks out as a
> very minimal subset.  Every now and then, when we update this module,
> some of the files become empty.  They were not empty before updating,
> and they are not empty in the repository.  Once we discover they are
> empty, we can remove them and update again, and they come out correct.
>
>  
>
> Additionally, this same module has Entries.Static files in it.  The
> Entries.Static explanation is  a bit vague to me. 
>
>  
>
> It says:
>
>  
>
>  If the CVS/Entries.Static file exists, it means that the entire
> directory has not been fetched from the repository.
>
>  
>
> Which is ok I'm guessing, because we do not extract the entire tree.
>
>  
>
> But, it also says:
>
>  
>
> The Entries.Static file is present during checkouts and updates and
> removed immediately when the operation is complete. If you see
> Entries.Static, it means that CVS was interrupted, and its presence
> prevents CVS from creating any new files in the working copy.
>
>  
>
> This Entries.Static file persists beyond the checkout process, and there
> was no interruption of the checkout process.  And these erroneously
> checked out files of zero length, live in the same directories where
> these Entries.Static files are found. 
>
>  
>
> So my questions:
>
>  
>
> 1.       Should these Static file markers exist in a sandbox after the
> checkout process has finished?

 From what you have from the files above I would _guess_ NO.

> 2.       Could the existence of these files be causing empty copies to
> be extracted upon subsequent extractions?  
>
> 3.       If changes were committed to a file in one of these directories
> AND the Entries.Static file exists, would that cause empty file updates?
>
> 4.       Do you have any suggestions, explanations for what conditions
> need to exist so that a zero length file stored in the repository is
> extracted as zero length?
>
>  
>
> I surely would appreciate any suggestions you may have!

A) what OS and version are you running this under?
[ with a Unix issue `uname -a` and paste the result in your email]

B) which version of cvs, i.e., issue `cvs --version` and paste the result in 
your email?

C) connection method [:ext:(with ssh/rsh),:pserver:...]?

D) OS and version of the server machine?

E) cvs version on the server machine?

F) does the sandbox exist on a local physical drive [(S)ATA, SCSI, USB, 
Firewire...], or on the network [NFS, AFS, SMB...]?

G) what if any front ends are you using [eclipse, TortoiseCVS, WinCVS...] when 
you see the fault?

H) do you see any errors when you run the command in a terminal?
i.e., can you capture a few runs like
`cvs co module > cologfile[123].txt 2>&1`
`cvs update > uplogfile[123].txt 2>&1`
and check for the Entries.Static to show up after each, look in the log file 
when you find the Entries.Static just after a run.

I) does (with the _permission_ of your network admin)
`ping -s 1400 -f -c 200 servermachine`
show any packet loss?

I would expect that the more senior members of the list could guess where in 
the code the Entries.Static files are being generated and should be blown away 
but they probably need to know more about your configuration to help track it 
down.


If the log files above don't show something when you see the faults, you may 
have to have cvs output trace info. `cvs --help-options`


--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter