[Top][All Lists]

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

Re: Sub-directories not getting added to CVS/Entries

From: Russ Sherk
Subject: Re: Sub-directories not getting added to CVS/Entries
Date: Thu, 17 Nov 2005 08:36:18 -0500

On 11/17/05, Spiro Trikaliotis <address@hidden> wrote:
Hallo Mark,

* On Wed, Nov 16, 2005 at 03:23:14PM -0700 Mark E. Hamilton wrote:

> I'm having a strange problem. When I do a cvs checkout it seems to work
> fine. However, if I immediately follow it with an update some
> sub-directories that it previously checked out show up with a '?'.  The
> sub-directory does not appear in the appropriate CVS/Entries file.
> However, the sub-directory does contain a CVS sub-directory.
> So, cvs checked it out, but now it doesn't know about it. This happens
> with multiple directories, but not all of them. Has anyone else seen
> this before?
> My checkout command looks like this:
> cvs -f -d :ext:<server>:/cvsroot/sntools checkout sntools

I have seen this behaviour when a Windows client is involved and the
repository contains two directories which only differ in case. Anyway,
this can occur anytime you want to check out the sandbox on an
case-insensitive file system.

For example:

Assume you have a docs/ and Docs/ directory in the repository. If you
check out, Windows maps both directories into the same local directory.

If this is the case, you may want to check that the  one of the [Dd]ocs/ directories has been incorrectly added to the cvs repository.  I had a similar error yesterday where in the repo there were 2 files test.txt an Test.txt.  Test.txt was the real cvs file and test.txt should never have existed. 

To test this you need to 'cvs log' a file that is in the directory (cvs log sntools/docs/FileLayout.txt; cvs log sntools/Docs/FileLayout.txt).  CVS should show a blank log message (no revisions, tags etc.) and the other should just spit out the log info.  If this is the case, you can probably just BACKUP and remove the /cvsroot/sntools/[dD]ocs/ directory that has files with 'no head revision'.


I assume Docs/ is empty (at least, for the current checkout), but docs/
is not. If these are not empty, the result is even worse than the one I
am describing here.

Assume Docs/ is given by the server before docs/: In this case, the
files in Docs/CVS/ are overwritten with the ones from docs/CVS/, which
does not do much harm.

Now, assume docs/ is given by the server before Docs/: In this case, the
files in docs/CVS/ are overwritten with the ones from Docs/CVS/.
Unfortunately, Docs/CVS/ has info about an empty directory. Now, CVS is
very confused.

I have helped myself in these cases by editing CVS/Entries.log and
changing the case of Docs to docs. Now, an update works as expected.

Notice: First, using -P on checkout does not help here, because CVS
first checks out everything and prunes the directories afterwards.
Secondly, do not use -d on check out, or your problem will come back.

> Finally, following a checkout command immediately with another one
> (which should basically be a no-op) generates a number conflict errors
> for files in all the directores which have this problem. (Not
> surprising, I suppose, given the other errors.)
> cvs checkout: Updating sntools/docs
> cvs checkout: move away sntools/docs/FileLayout.txt; it is in the way
> C sntools/docs/FileLayout.txt
> cvs checkout: move away sntools/docs/glossary.html; it is in the way
> C sntools/docs/glossary.html
Yes, this sounds exactly like the problem I am describing above.

> The client and server I'm using are these:

I have seens this problem with 1.11 and 1.12 versions of CVS.

I remember seeing a post that special handling of Windows file systems
was removed from the server in some 1.11.x version. Perhaps, this
problem is related to this one?

Ah, I found it:

Changes between 1.12.2 and 1.12.3:



* Support for case insensitive clients has been removed.  This
  is not as drastic as it sounds, as all of the current tests still pass
  without modification when run from a case insensitive client to a case
  sensitive server.  In the end this should provide a major stability


I have reported this problem before and even provided a script which
shows this behaviour:

There, I only spoke of problems with release, but updates are
problematic, too.


Spiro R. Trikaliotis                               

Info-cvs mailing list

reply via email to

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