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

[Spiro Trikaliotis]

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.

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:
**********************************

[...]

GENERAL USER ISSUES

* 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
  improvement.

[...]


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

   http://lists.gnu.org/archive/html/info-cvs/2004-06/msg00343.html

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

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis                              http://cbm4win.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/