[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nees help, some files checkout as empty

From: Todd Denniston
Subject: Re: Nees help, some files checkout as empty
Date: Thu, 31 Jan 2008 13:19:27 -0500
User-agent: Thunderbird (X11/20071031)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]