Re: Ampersand module question
In PkXs8.421$[EMAIL PROTECTED] Jay Glanville [EMAIL PROTECTED] writes: Thanks Martin. It's a good start, but not all that I was looking for. By using the -d option, what I'm doing is front-loading the naming architecture. In other words, anytime I use module amp1, it will be under a directory tools I create dummy modules for that purpose. For example, amp1path/to/amp1 amp2path/to/amp2 _amp1 -d tools/amp1 path/to/amp1 mod path/to/mod _amp1 amp2 The convention is that a module beginning with an underscore is not meant to be checked out by itself --although nothing prevents you to. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ampersand module question
Pierre Asselin [EMAIL PROTECTED] wrote in message a92viq$oed$[EMAIL PROTECTED]">news:a92viq$oed$[EMAIL PROTECTED]... In PkXs8.421$[EMAIL PROTECTED] Jay Glanville [EMAIL PROTECTED] writes: Thanks Martin. It's a good start, but not all that I was looking for. By using the -d option, what I'm doing is front-loading the naming architecture. In other words, anytime I use module amp1, it will be under a directory tools I create dummy modules for that purpose. For example, amp1path/to/amp1 amp2path/to/amp2 _amp1 -d tools/amp1 path/to/amp1 mod path/to/mod _amp1 amp2 The convention is that a module beginning with an underscore is not meant to be checked out by itself --although nothing prevents you to. Thanks Pierre. This makes sense. JDG ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ampersand module question
In [EMAIL PROTECTED] Martin Heinen [EMAIL PROTECTED] writes: On Tue, Apr 09, 2002 at 01:09:27PM +, Jay Glanville wrote: [ ... ] Now, is there a way to say that module amp1 should be included in module mod and be placed in a directory called tools. For example, when I do a checkout of module mod, I get the following directories: mod mod/tools/amp1 mod/amp2 The -d option renames the working directory: | amp1 -d mod/tools/amp1 amp1 | amp2 amp2 | mod amp1 amp2 I think it should be '-d tools/amp1', the 'mod/' is implied by the amperstand mechanism. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ampersand module question
Martin Heinen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Tue, Apr 09, 2002 at 01:09:27PM +, Jay Glanville wrote: When a module has an ampersand module as part of it's definition, the ampersand module gets included in the root of the other module. My questio is: is there a way to have the ampersand module included in a subdirectory? For example, if my modules file looks something like this: amp1 amp1 amp2 amp2 mod amp1 amp2 then when I do a: cvs co mod I get a directory structure that looks like this: mod mod/amp1 mod/amp2 Now, is there a way to say that module amp1 should be included in module mod and be placed in a directory called tools. For example, when I do a checkout of module mod, I get the following directories: mod mod/tools/amp1 mod/amp2 The -d option renames the working directory: | amp1 -d mod/tools/amp1 amp1 | amp2 amp2 | mod amp1 amp2 Module options are described in http://www.cvshome.org/docs/manual/cvs_18.html#SEC160 HTH, Martin Thanks Martin. It's a good start, but not all that I was looking for. By using the -d option, what I'm doing is front-loading the naming architecture. In other words, anytime I use module amp1, it will be under a directory tools (i.e.: cvs co amp1 will result in tools/amp1). Another example: along with module mod is module othermod, which has a definition of othermod amp1. It will automaticly be placed in a directory called othermod/tools/amp1. I may not want it there. Is there a way to back-load where the ampersand module will be included? For example, to be able to say that in module mod, include module amp1 in the location mod/tools, and for module othermod, include module amp1 in location othermod/loadbuild? I suppose another word to describe what I'm trying to do is make a link to another module. In ClearCase parlance, I'd be making a link (at a location of my choosing) to another vob (equivalent to a module). Thanks JDG -- Jay Dickon Glanville ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Ampersand module question
I have a question concerning ampersand modules, and I'm hoping someone here can help me. When a module has an ampersand module as part of it's definition, the ampersand module gets included in the root of the other module. My questio is: is there a way to have the ampersand module included in a subdirectory? For example, if my modules file looks something like this: amp1 amp1 amp2 amp2 mod amp1 amp2 then when I do a: cvs co mod I get a directory structure that looks like this: mod mod/amp1 mod/amp2 Now, is there a way to say that module amp1 should be included in module mod and be placed in a directory called tools. For example, when I do a checkout of module mod, I get the following directories: mod mod/tools/amp1 mod/amp2 Is this possible? Thanks, JDG -- Jay Dickon Glanville ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ampersand module question
On Tue, Apr 09, 2002 at 01:09:27PM +, Jay Glanville wrote: When a module has an ampersand module as part of it's definition, the ampersand module gets included in the root of the other module. My questio is: is there a way to have the ampersand module included in a subdirectory? For example, if my modules file looks something like this: amp1 amp1 amp2 amp2 mod amp1 amp2 then when I do a: cvs co mod I get a directory structure that looks like this: mod mod/amp1 mod/amp2 Now, is there a way to say that module amp1 should be included in module mod and be placed in a directory called tools. For example, when I do a checkout of module mod, I get the following directories: mod mod/tools/amp1 mod/amp2 The -d option renames the working directory: | amp1 -d mod/tools/amp1 amp1 | amp2 amp2 | mod amp1 amp2 Module options are described in http://www.cvshome.org/docs/manual/cvs_18.html#SEC160 HTH, Martin -- Marxpitn ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Ampersand module question
I'm curious about ampersand modules. Once a regular module (containing another module via the "" construct) is checked out, does that module actually *know* that it contains the contained module? If my modules file says something like this: frobnicator frobnicator caturgiator ...and I do this: cvs checkout -P frobnicator ...then I get this (as expected): frobnicator/somedir frobnicator/caturgiator/someotherdir ...but now if I do this: cd frobnicator; rm -rf caturgiator; cd .. ...and then do this: cvs -q update -d -P -A ...then caturgiator does not reappear, suggesting that frobnicator's CVS directory does not record what the modules file engineered to happen. The only way to set this back up would be to re-checkout the project or checkout the caturgiator module directly at this level. Is that by design? Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ampersand module question
Laird Nelson [EMAIL PROTECTED] writes: I'm curious about ampersand modules. Once a regular module (containing another module via the "" construct) is checked out, does that module actually *know* that it contains the contained module? If my modules file says something like this: frobnicator frobnicator caturgiator ...and I do this: cvs checkout -P frobnicator ...then I get this (as expected): frobnicator/somedir frobnicator/caturgiator/someotherdir ...but now if I do this: cd frobnicator; rm -rf caturgiator; cd .. ...and then do this: cvs -q update -d -P -A ...then caturgiator does not reappear, suggesting that frobnicator's CVS directory does not record what the modules file engineered to happen. Correct. there isn't enough info about submodules in the upperlevel CVS directory to bring it back, and cvs update ignores the modules file. The only way to set this back up would be to re-checkout the project or checkout the caturgiator module directly at this level. I believe if you do cvs checkout from above the toplevel of an existing work directory, and it will update what's already there, and add anything new that it finds in the modules file. It won't *remove* anything that was taken out of the modules file, though. Is that by design? It seems more likely it was just an accident of implementation. The entire modules file concept doesn't seem very well thought out to me; more like an afterthought tacked on one rainy afternoon... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Ampersand module question
On Wednesday, November 29, 2000 10:22 AM, Laine Stump [SMTP:[EMAIL PROTECTED]] wrote: Laird Nelson [EMAIL PROTECTED] writes: I'm curious about ampersand modules. Once a regular module (containing another module via the "" construct) is checked out, does that module actually *know* that it contains the contained module? If my modules file says something like this: frobnicator frobnicator caturgiator ...and I do this: cvs checkout -P frobnicator ...then I get this (as expected): frobnicator/somedir frobnicator/caturgiator/someotherdir ...but now if I do this: cd frobnicator; rm -rf caturgiator; cd .. ...and then do this: cvs -q update -d -P -A ...then caturgiator does not reappear, suggesting that frobnicator's CVS directory does not record what the modules file engineered to happen. Correct. there isn't enough info about submodules in the upperlevel CVS directory to bring it back, and cvs update ignores the modules file. The only way to set this back up would be to re-checkout the project or checkout the caturgiator module directly at this level. I believe if you do cvs checkout from above the toplevel of an existing work directory, and it will update what's already there, and add anything new that it finds in the modules file. It won't *remove* anything that was taken out of the modules file, though. Is that by design? It seems more likely it was just an accident of implementation. The entire modules file concept doesn't seem very well thought out to me; more like an afterthought tacked on one rainy afternoon... This seems to be (on my quick look) an artifact of the files in the CVS directory. Entries contains the directories (and files) which have been checked out. Entries will have a D line for caturgiator. However CVS does an update by recursing into each directory in the current directory and doing an update there. In this case caturgiator doesn't have a directory so it can't be recursed into. CVS then goes into the repository in the location specified in Repository and tries to recreate files and directories that are in Entries, but not visible in the current directory. In this case caturgiator is not in the Repository location, so can't be updated. I guess the short answer is not to delete caturgiator once you've checked it out. It seems to me that the intention of the modules file was to allow you to perform several checkouts at one time, using an 'alias' instead of having to remember all the repository locations. *** Chris CameronOpen Telecommunications NZ Ltd Product Manager IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
