missing files after cvs checkout

[David Shrader]

Hello All,

I have run into an issue that has stumped everyone I work with that uses CVS,
so I thought I would present it to the larger CVS community.

In a code project that I have just been asked to help out, certain files fail
to be checked out during a checkout or update. The only way to get these files
is to check them out specifically, which is rather annoying. For example,

cvs -d <repo> co -P <directory>

checks out all but six of the needed files. Without these files, compilation of
course fails. I have tried the following:

cvs update -dP

This fails to get the required files. I have tried this command both in the top
level directory and the directory that the files should reside in, and both
fail to get the files. The only way to get the files is to run the following for
each file:

cvs update -dP <path>/<file>

I can use 'co' instead of update and can get the same result. Before getting
the file, I can successfully get the status of the file by using 'cvs status
<path>/<file>'. There are no sticky dates or tags associated with any of the
files.

Does anyone understand what might be going on? What do we need to do to get
the "missing" files working with a regular checkout?

One piece of information that might be helpful is that all six of the files
were added later to the project. They were not part of the initial check-in
(the team only recently adopted CVS, so the code was quite mature by the time
of initial creation of the repository). As far as we can tell, every file that
was added after the initial check-in exhibits this same behavior. Any
suggestions?

Thank you for any and all help!
David
--
David Shrader
Los Alamos National Lab
HPC: System Integration
***@lanl.gov

[Larry Jones]

Post by David Shrader
In a code project that I have just been asked to help out, certain files fail
to be checked out during a checkout or update. The only way to get these files
is to check them out specifically, which is rather annoying.

Check the repository -- it's likely that those files are incorrectly
located in the Attic subdirectory (only files that don't exist on the
tip of the trunk should be in the Attic). There was a bug in some
old versions of CVS that neglected to move files out of the Attic in
some cases. If that is the problem, you can just manually move the
files (and update your CVS to a reasonably recent version if you haven't
already).

[Jim Hyslop]

Post by David Shrader
In a code project that I have just been asked to help out, certain files fail
to be checked out during a checkout or update. The only way to get these files
is to check them out specifically, which is rather annoying. For example,
cvs -d <repo> co -P <directory>
checks out all but six of the needed files. Without these files, compilation of

Check to see if you have any sticky tags set. 'cvs update -A' will clear
any sticky tags.


- --
Jim Hyslop
Dreampossible: Better software. Simply. http://www.dreampossible.ca
Consulting * Mentoring * Training in
C/C++ * OOD * SW Development & Practices * Version Management

[Jim Hyslop]

Post by David Shrader
There are no sticky dates or tags associated with any of the
files.

If Larry's suggestion about the Attic doesn't work, compare the default
branch for the six problem files with the default branch of the files
that are good. Do this by issuing the command `cvs rlog -h
<path>/<file>`, and look at the "branch: " line. If they're different,
you can change the default branch with the command `cvs admin -b`.

- --
Jim Hyslop
Dreampossible: Better software. Simply. http://www.dreampossible.ca
Consulting * Mentoring * Training in
C/C++ * OOD * SW Development & Practices * Version Management

[David Shrader]

Hello,

Thank you Larry and Jim for the quick replies. I'm working on Larry's
suggestion. The repository is kept on another machine that hosts many
projects, and we're finding that it isn't easy to get at the repository. We're
working on it, and I will report back.

Since Jim's suggestion I could easily do, I tried it. The "branch:" line for
the problem files are the same as for ok files. It is always blank.

Thank you again!
David

Post by Jim Hyslop

Post by David Shrader
There are no sticky dates or tags associated with any of the
files.

If Larry's suggestion about the Attic doesn't work, compare the default
branch for the six problem files with the default branch of the files
that are good. Do this by issuing the command `cvs rlog -h
<path>/<file>`, and look at the "branch: " line. If they're different,
you can change the default branch with the command `cvs admin -b`.

[Mark D. Baushke]

Hi David,

Actually, you can determine where it is in the repository using the
CVS command:

cvs log filename

The 'RCS File' will include the '/Attic/' component if the filename is
indeed in the Attic. Then looking to see the 'state: ' of the 'head:'
revision should tell you if it is right or not.

For exaqmple, if 'head: 1.33' is found and the data looks something like this:

RCS file: /path/to/file/Attic/name.c
...
head: 1.33
...
revision 1.33
date: yyyy-mm-dd hh:mm:ss +0000; author: xx; state: dead; lines +0 -0;
...

then there is nothing wrong. However, if the state is something else
like 'state: Exp;' then you have run into the older 'cvs' bug.

Good luck,
-- Mark

[David Shrader]

Hello Mark,

Thank you for the command! It looks like that we have run into the older cvs
bug. The output from 'cvs log' puts the file's location in the Attic, and the
state of the most recent version is "state: Exp;". We're still working on
getting access to the repository, so we aren't able to make the change
ourselves quite yet. Just to make sure I understand what needs to happen, all
we have to do is move the ,v files of the problem files from the Attic
subdirectory up one directory, and all should be ok? After that, run an update
to get the workspace all squared away?

Thank you all again for the help!
David

Post by Mark D. Baushke
Hi David,
Actually, you can determine where it is in the repository using the
cvs log filename
The 'RCS File' will include the '/Attic/' component if the filename is
indeed in the Attic. Then looking to see the 'state: ' of the 'head:'
revision should tell you if it is right or not.
RCS file: /path/to/file/Attic/name.c
...
head: 1.33
...
revision 1.33
date: yyyy-mm-dd hh:mm:ss +0000; author: xx; state: dead; lines +0 -0;
...
then there is nothing wrong. However, if the state is something else
like 'state: Exp;' then you have run into the older 'cvs' bug.
Good luck,
-- Mark

[Mark D. Baushke]

Post by David Shrader
Thank you for the command! It looks like that we have run into the
older cvs bug. The output from 'cvs log' puts the file's location in
the Attic, and the state of the most recent version is "state: Exp;".
We're still working on getting access to the repository, so we aren't
able to make the change ourselves quite yet. Just to make sure I
understand what needs to happen, all we have to do is move the ,v
files of the problem files from the Attic subdirectory up one
directory, and all should be ok? After that, run an update to get the
workspace all squared away?

Correct.

Doing something like this:

mv /path/to/file/Attic/name.c,v /path/to/file/name.c,v

should solve your problem. Of course, you should also update your
cvs server version to avoid this problem in future.

-- Mark

[David Shrader]

Hello All,

The situation has finally been resolved! Thank you all for your help. For some
reason, doing a forced check-in didn't move files out of the Attic. However, we
did finally work with the admins of the server the repository is located on,
and they moved the problem files from the Attic subdirectory to where they
should be. All files now check out as expected.

Thank you again!
David

Post by Mark D. Baushke

Post by David Shrader
Thank you for the command! It looks like that we have run into the
older cvs bug. The output from 'cvs log' puts the file's location in
the Attic, and the state of the most recent version is "state: Exp;".
We're still working on getting access to the repository, so we aren't
able to make the change ourselves quite yet. Just to make sure I
understand what needs to happen, all we have to do is move the ,v
files of the problem files from the Attic subdirectory up one
directory, and all should be ok? After that, run an update to get the
workspace all squared away?

Correct.
mv /path/to/file/Attic/name.c,v /path/to/file/name.c,v
should solve your problem. Of course, you should also update your
cvs server version to avoid this problem in future.
-- Mark

[Larry Jones]

Post by David Shrader
Thank you for the command! It looks like that we have run into the older cvs
bug. The output from 'cvs log' puts the file's location in the Attic, and the
state of the most recent version is "state: Exp;". We're still working on
getting access to the repository, so we aren't able to make the change
ourselves quite yet.

If you're running a recent version of CVS, just forcing a checkin
without any changes should get CVS to move the file for you.

[Larry Jones]

Post by David Shrader
The situation has finally been resolved! Thank you all for your help. For some
reason, doing a forced check-in didn't move files out of the Attic.

That strongly implies that the version of CVS on your server is buggy
and should be upgraded ASAP.

[Amaresh Ch Das]

try with this command

steps:-
do cvs update first using cvs update <project_dir>cvs -q up -Pd  <project_dir>cvs -d <repositary> co -P <project_dir>

Thanks,
Amaresh Chandra Das
www.eodissa.com




--- On Thu, 12/8/10, Jim Hyslop <***@dreampossible.ca> wrote:

From: Jim Hyslop <***@dreampossible.ca>
Subject: Re: missing files after cvs checkout
To: "David Shrader" <***@lanl.gov>
Cc: info-***@nongnu.org
Date: Thursday, 12 August, 2010, 9:25 AM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by David Shrader
In a code project that I have just been asked to help out, certain files fail
to be checked out during a checkout or update. The only way to get these files
is to check them out specifically, which is rather annoying. For example,
cvs -d <repo> co -P <directory>
checks out all but six of the needed files. Without these files, compilation of

Check to see if you have any sticky tags set. 'cvs update -A' will clear
any sticky tags.


- --
Jim Hyslop
Dreampossible: Better software. Simply.     http://www.dreampossible.ca
                 Consulting * Mentoring * Training in
    C/C++ * OOD * SW Development & Practices * Version Management