> Hello all,
>
> Win2K> cvs -t -d :server:user@linuxbox:/home/user/repository checkout .
>
> cvs checkout: notice: main loop with
> CVSROOT=:server:user@linuxbox:/home/user/repository
> S-> so_module (., Updating, , )
> cvs checkout: cannot open CVS/Entries for reading: No such file or
> directory
> cvs [checkout aborted]: no repository
>
This is a bug in the filename routines on the Win32 version of CVS. The
attached patch fixed this problem for me on 1.10.5. It needs to be
applied in the windows-NT directory.
Unless there are massive changes it will probably apply cleanly to the
1.11 sources. I could probably build a 1.11 CVS client with this patch
if you don't have the capability to build CVS from source.
Mike
Index: filesubr.c
===================================================================
RCS file: /projects/mpc_data/grandmet/cvs_src/windows-NT/filesubr.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** filesubr.c 1999/09/02 16:26:25 1.1.1.2
--- filesubr.c 1999/09/23 07:29:07 1.1.1.2.2.1
***************
*** 783,796 ****
char *last_forw_slash, *last_back_slash, *end_of_dirname;
int dirname_length = 0;
! /* FIXME: If argv[i] is ".", this code will expand it to the
! name of the current directory in its parent directory which
! will cause start_recursion to do all manner of strange things
! with it (culminating in an error). This breaks "cvs co .".
! As nearly as I can guess, this bug has existed since
! expand_wild was first created. At least, it is in CVS 1.9 (I
! just tried it). */
!
/* FindFirstFile doesn't return pathnames, so we have to do
this ourselves. Luckily, it's no big deal, since globbing
characters under Win32s can only occur in the last segment
--- 783,799 ----
char *last_forw_slash, *last_back_slash, *end_of_dirname;
int dirname_length = 0;
! /* If argv[i] is ".", we don't want to expand it since it is
! * already a fully expanded reference to the current directory . */
! if (strcmp(argv[i],".") == 0) {
! new_argv[new_argc++] = xstrdup (argv[i]);
! if (new_argc == max_new_argc)
! {
! max_new_argc *= 2;
! new_argv = xrealloc (new_argv, max_new_argc * sizeof (char *));
! }
! break; /* done for this pass */
! }
/* FindFirstFile doesn't return pathnames, so we have to do
this ourselves. Luckily, it's no big deal, since globbing
characters under Win32s can only occur in the last segment
