Hi,just wondering if someone can help me with a CVS command line-issue. I'm moving my drupal development files from my windows box to my test server which doesn't have a GUI. I'm doing this because I am sick of windows corrupting my files, changing the new-line characters so that I can't make patches.Anyway.First, I create the environment variable for the default directory, that seems fine:export CVSROOT=/cvswebthen I logincvs -z3 -d:pserver:anonymous@cvs.drupal.org:/cvs/drupal-contrib loginand downloadcvs -z3 -d:pserver:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout contributions/modules/mmcontributeBut when I download the files are not going to the /cvsweb/ directory as I'd like, it's going to the user's home directory.TIA, Simon.
CVSROOT is a big long string that defines the SOURCE (and protocol) of the CVS repository - the central remote one.Your CVSROOT is in fact:pserver:anonymous@cvs.drupal.org:/cvs/drupal-contribSo you could have set it onceexport CVSROOT=:pserver:anonymous@cvs.drupal.org:/cvs/drupal-contribAnd not needed to do so again. Cvs logincvs checkout contributions/modules/mmcontributeAnyway, you just want to cd to /cvsweb when you go to checkout, or read the CVS docs to see how to direct it into a directory of your choice.And don't blame windows for your newlines. Get a decent text editor, or at least learn how to use the file format options of the one you use.dan. Export CVSROOT=:pserver:anonymous@cvs.drupal.org:/cvs/drupal-contribcvs loginmkdir cvswebcd cvswebcvs checkout contributions/modules/mmcontributeWorked for me.Or if you insist on not just going 'cd' as suggested initially as the easy, obvious way, you'll find the instructions in the usual (F-ing) place cvs cvsoptions cvscommand commandoptions commandargs So cvs checkout -d cvsweb -N contributions/modules/mmcontributeWorks, and even -d /cvsweb would probably be ok.' -d cvsweb' and -N are commandoptions passed to the cvscommand.The path identifier of the module is the commandarg.Your attempts 'didn't work' because they were wrong.
One more random guess would probably have got you there though:-BI used the -N, because that's needed if we want to replicate the remote structure of the repository so as to install other modules side-by side.An acceptable alternative is to give your local directory (-d) a proper path (including the name of the module you are grabbing) cvs checkout -d cvsweb/modules/mmcontribute contributions/modules/mmcontributeIt IS all there, and in other documentation. It IS complicated because it's so powerful and configurable, but it DOES require some trial and error to get it right. I certainly ended up with a few overlaying checkouts when I started off, and then I found the 'anonymous' checkouts couldn't co-exist nicely with my authenticated check-ins.If you start doing unclean checkouts (which create the CVS folders in your system as it goes) you can look directly at the configs and see where everything has come from. The CVS folders remember exactly what the CVSROOT was when you retrieved the file, and all cvs commands done once you've changed into that directory will use these settings automatically, which is a real boon. You can wander in there any time in the future and just saycvs update with no arguments and the rest is totally automatic!but you have to start using it to see how it works.dan.
On 2009-11-25 Hugh Sorby wrote: Sorry about that missed a chdir should be cmake -E chdir netgen patch -p0 -i netgen-4.9.11.patchI confirm that you have found a bug (at least with Debian stable Linux and abootstrapped cmake version 2.8.0-rc6). Here is a simple demonstrationwith 'ls -i'.software@raven ls -i config.h4539478 config.hsoftware@raven cmake -E chdir. Ls -i config.hconfig.hIn other words the ls -i option is consumed by CMake just like the patch -ioption is consumed for you. Note that -i is anoption for CMake itself (wizard mode) so there is probably some screwupin interpretation of the command line when cmake -E is being run.If I change the flag from -i to -l, then the flag is not consumed andyou get the same results for'ls -l config.h' and 'cmake -E chdir. Ls -l config.h'.
That's consistentwith the idea that you will only have trouble with cmake consuming theoption when it is an option it recognizes. ('-l' is not a cmake commandoption while '-i' is).I also confirm the bug occurs for cmake-2.6.0 (the Debian stable systemversion) which makes it a bug that has been around for quite a while. Isuggest you go ahead and put it in the bugtracker (if you cannot findanother report about the same issue there).Until this cmake -E option consuming bug is fixed I suggest you could avoidthe -i option with patch by using, e.g.,cmake -E chdir netgen patch -p0. On 2009-11-25 Hugh Sorby wrote: Sorry about that missed a chdir should be cmake -E chdir netgen patch -p0 -i netgen-4.9.11.patch I confirm that you have found a bug (at least with Debian stable Linux and a bootstrapped cmake version 2.8.0-rc6).
Here is a simple demonstration with 'ls -i'. software@raven ls -i config.h 4539478 config.h software@raven cmake -E chdir. Ls -i config.h config.h In other words the ls -i option is consumed by CMake just like the patch -i option is consumed for you. Note that -i is an option for CMake itself (wizard mode) so there is probably some screwup in interpretation of the command line when cmake -E is being run. If I change the flag from -i to -l, then the flag is not consumed and you get the same results for 'ls -l config.h' and 'cmake -E chdir. Ls -l config.h'.
That's consistent with the idea that you will only have trouble with cmake consuming the option when it is an option it recognizes. ('-l' is not a cmake command option while '-i' is). I also confirm the bug occurs for cmake-2.6.0 (the Debian stable system version) which makes it a bug that has been around for quite a while. I suggest you go ahead and put it in the bugtracker (if you cannot find another report about the same issue there). Until this cmake -E option consuming bug is fixed I suggest you could avoid the -i option with patch by using, e.g., cmake -E chdir netgen patch -p0 Alan Alan W.
Irwin wrote:On 2009-11-25 Hugh Sorby wrote:Sorry about that missed a chdir should becmake -E chdir netgen patch -p0 -i netgen-4.9.11.patchI confirm that you have found a bug (at least with Debian stable Linux and abootstrapped cmake version 2.8.0-rc6). Here is a simple demonstrationwith 'ls -i'.software@raven ls -i config.h4539478 config.hsoftware@raven cmake -E chdir. Ls -i config.hconfig.hIn other words the ls -i option is consumed by CMake just like the patch -ioption is consumed for you. Note that -i is anoption for CMake itself (wizard mode) so there is probably some screwupin interpretation of the command line when cmake -E is being run.If I change the flag from -i to -l, then the flag is not consumed andyou get the same results for'ls -l config.h' and 'cmake -E chdir.
Ls -l config.h'. That's consistentwith the idea that you will only have trouble with cmake consuming theoption when it is an option it recognizes. ('-l' is not a cmake commandoption while '-i' is).I also confirm the bug occurs for cmake-2.6.0 (the Debian stable systemversion) which makes it a bug that has been around for quite a while. Isuggest you go ahead and put it in the bugtracker (if you cannot findanother report about the same issue there).Until this cmake -E option consuming bug is fixed I suggest you could avoidthe -i option with patch by using, e.g.,cmake -E chdir netgen patch -p0. On 2009-11-25 Hugh Sorby wrote: I found this but didn't manage to reopen it so I submitted this bug report It is interesting that Bug 6945 was closed as fixed in CVS by Bill Hoffmanmore than a year ago. So I suspect the trouble is this fix never made itinto a release (yet).AlanAlan W.
For now, another workaround would be to write a script that calls patch with the -i argument and then invoke the script with executeprocess or a different cmake -E command line. On Tue, Nov 24, 2009 at 7:43 PM, Hugh Sorby wrote: Thanks Alan, I will attempt to: 1) search the CMake bug tracker (not very good at this most never seem to find anything relevant) 2) add new bug if 1) fails to bear any fruit.
Unfortunately the cmake -E chdir netgen patch -p0 doesn't work so well on Windows Vista which is why I was trying to use the -i option. Alan W. Irwin wrote: On 2009-11-25 Hugh Sorby wrote: Sorry about that missed a chdir should be cmake -E chdir netgen patch -p0 -i netgen-4.9.11.patch I confirm that you have found a bug (at least with Debian stable Linux and a bootstrapped cmake version 2.8.0-rc6). Here is a simple demonstration with 'ls -i'. software@raven ls -i config.h 4539478 config.h software@raven cmake -E chdir. Ls -i config.h config.h In other words the ls -i option is consumed by CMake just like the patch -i option is consumed for you. Note that -i is an option for CMake itself (wizard mode) so there is probably some screwup in interpretation of the command line when cmake -E is being run.
Acme Patch Command
If I change the flag from -i to -l, then the flag is not consumed and you get the same results for 'ls -l config.h' and 'cmake -E chdir. Ls -l config.h'. That's consistent with the idea that you will only have trouble with cmake consuming the option when it is an option it recognizes. ('-l' is not a cmake command option while '-i' is). I also confirm the bug occurs for cmake-2.6.0 (the Debian stable system version) which makes it a bug that has been around for quite a while. I suggest you go ahead and put it in the bugtracker (if you cannot find another report about the same issue there). Until this cmake -E option consuming bug is fixed I suggest you could avoid the -i option with patch by using, e.g., cmake -E chdir netgen patch -p0 Alan Alan W.
Apply Patch Without Sewing
On 2009-11-25 Hugh Sorby wrote: I found this but didn't manage to reopen it so I submitted this bug report It is interesting that Bug 6945 was closed as fixed in CVS by Bill Hoffman more than a year ago. So I suspect the trouble is this fix never made it into a release (yet).Nope, just not fixed for this case.Looks like -i and -system-information will not work with -E, both willbe consumed by CMake.:(Should be easy to fix. Will have it fixed in 2.8.1.-BillPowered by www.kitware.comVisit other Kitware open-source projects at Please keep messages on-topic and check the CMake FAQ at: Follow this link to subscribe/unsubscribe.