Problem: newly creating local CVS tree using CVS pserver Hi, Aren't there serious discrepancies in the given instruction and the reality of newly creating a local CVS tree on one's computer using CVS pserver "CVS checkout" command in the following URL? http://www.xfree86.org/cvs/ Problem was that a few days ago, I could not create a new CVS tree from scratch in a successful format using the "anoncvs via cvs pserver". "cvs checkout xc" only fetched the subsets of the required files and so I could not run "make World" or "make Everything" without seeing a few key components. This is VERY STRANGE since when I created a local CVS tree from scratch a few years ago (or possibly just one year ago), it worked like a charm. (But I am not sure if I used CVS pserver, or CVSup [or even manually copied *.tgz files and expanded it locally] initiailly.) Or, has there been either - a reorganization of CVS module naming structure in the last 12 months or so, (very, very unlikely), - a replacement of CVS pserver, which may result in a strange limiting of output from the server (maybe a la quota) to the local user machines (again unlikely), or - a new TCP/IP connection time limit outside the knowledge of CVS pserver? Some Background: A couple of years ago or so, I set up my local CVS copy of XFree86 source tree. (Now I don't recall if I used CVSup or cvs checkout (using pserver) to populate my local tree initially. I may have even used the various *.tgz files and expanded them manually. The method is important in the following discussion.) The local tree worked well that time. I could track the latest development of ATI video chip drivers, and I was happy. For updating, I used CVS update command using pserver and this worked well, too. Problem: I have not updated my local copy of CVS tree for, maybe almost a year, and just the other day, I tried to update the local CVS copy and found that in the process, one of the config files got mangled. (This didn't happen back when I used CVS successfully.) Obviously, either the rarely touched configuraton file was modified on the Xfree86 server (likely), or I modified the local copy inadvertedly (also likely). I looked at the strange mangling that occurred and found that it was a editing collision, naturally. However, there are also a few discrepancies I could not clearly explain and straighten out in other parts of the compilation failure. Time to re-create the CVS source tree from scratch, I thought. So I removed the old CVS tree and started to recreate a local CVS tree. Having almost forgotten how I initially populated the local CVS copy from scratch, this time, I simply used cvs checkout xc to retrieve the source tree. (This is basically the one proposed near the bottom of the above URL just before "DISCLAIMER:" when we use CVS command. The other method would be using CVSup (or copying the *.tgz files and expanding them. But manual copying would have difficulty to keep up with the later changes. CVS meta directories need to be created any way for future upkeep. So CVSup would be the next choice.) Then I encountered a problem. The obtained CVS tree was so incomplete that it didn't even compile imake (during the initial part of make World) and aborted. First of all, the compiler could not find Xosdefs.h. This was too weired, and I looked inside the newly created "xc" directory and to my surprise, "lib", "include", "programs" and a few other important directories that should be there were not there. Eventually, I figured that now I NEEDED to check out additional modules aside from "xc". (But why? CVS command is supposed to work recursively.) Some of the modules I tried to check out are as follows (may not be the complete list.). cvs checkout xc <--- this was the one done initially. cvs checkout include <-- I needed Xosdefs.h cvs checkout nls <-- This directory was missing. I found the error in world.log about missing directory. cvs checkout programs <-- Ooops, the server itself was not and so it should be in the cvs checkout lib <--- server would have needed various libraries, so I copied this in advance. cvs checkout fontsscaled <--- my try to fetch scaled font directory which was missing again. The modules are added one by one to eradicate strange server compilation errors, etc.. (This is very strange. I thought that CVS would fetch the subdirectories automatically !?.) But now, I still can't seem to fill in the fonts/encodings directory. The directory fonts/encodings are clearly there on the cvsweb server. http://cvsweb.xfree86.org/cvsweb/xc/fonts/ I fetched the modules/modules file to figure out if there is a separate entry for fonts/encodings directory, but no there is not. I thought "cvs checkout fontsscaled" would have fetched these subdirectories automagically. But it didn't. * Something is very wrong. * Has the latest CVS command stopped creating/copying/updating recursively (recursively visiting subdirectories if necessary)? Or the CVS pserver on the xfree86 hosts thus restricted? (I am using ssh as the transport mechanism. This is the environment variable setup I use today. CVS_RSH=ssh # # anoncvs2 server # CVSROOT=:pserver:anoncvs@anoncvs2.xfree86.org:/cvs export CVS_RSH CVSROOT cf. then I login cvs login and run cvs update modulenames, etc.. ) I even swtichted the server to anoncvs2 from anoncvs just to see if it made much different when I found that "cvs checkout xc" fetched only the SUBSETS of subdirectories below xc. But it didn't make a difference. I am using anoncvs2 for now. I am stumped. Has anyone seen similar problems lately? I am using Debian GNU/Linux (the latest including the testing distribution) and the linux kernel 2.4.18. While I don't rule out that the latest Debian CVS tool may be miscompiled or something, but the problem of this nature must have been noticed by user population by now and the CVS problem would have been fixed. (Hmm... The directroy traversal routine in new glibc or something is broken or miscompiled. A possibility.) Any hints and tips would be appreciated. Chiaki PS: Yes, initially I thought maybe I used the manual copying of tar files (*.tgz) and expanded or something. But then I do realize that the subsequent cvs update would not have worked without CVS meta directories. So maybe I used CVSup instead. Has anyone built local CVS tree from scratch successfully using anonymous CVS pserver and checkout command? PPS: I was desperately trying to figure out what command I used to create the local CVS tree before. Then I found a following shell script (timestamped september 2001) in my bin directory and so maybe I used cvs checkout command and then at the time it was created and used, it worked just fine. (-z 2 is for using compression.) Hmm.... The contents of the script: : CVS_RSH="ssh" CVSROOT=anoncvs@anoncvs.xfree86.org:/cvs export CVS_RSH CVSROOT cd /ide-s-master/tools/xfree86-cvs cvs -z 2 checkout xc PPPS: Maybe I should simply try re-creating the local CVS tree. But this puts a burden on the xfree86 hosts and network unnecessarily and so until I hear some tips or bug info, I won't do so. _______________________________________________ Newbie@XFree86.Org *** To unsubscribe , or change message options, see: http://XFree86.Org/mailman/listinfo/newbie
