Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Bo Berglund wrote: > Regular module: > ---------------- > ModuleReg RepoModule Note that there are some variations of regular modules as well: ModuleFiles RepoModule File1 File2 File3 This will only check out File1, File2 and File3 from the RepoModule module into a target folder named ModuleFileReg. No other files or subfolders of the RepoModule module will be checked out. ModuleOverride -d TargetModule RepoModule Checking out ModuleOverride will checkout the contents of RepoModule into a folder named TargetModule. Note that you could combine this with the above file filter, i.e. : ModuleOverrideWFiles -d TargetModule RepoModule File1 File2 File3 Checking out ModuleOverrideWFiles will only check out File1, File2 and File3 from the RepoModule module into a target folder named TargetModule. In theory there's also this: ModuleLocal -l RepoModule ...which is supposed to only check out the files from RepoModule but none of its sub folders into a folder called ModuleLocal. Great. That would relieve you of having to explicitly specify the files (as in the first example above). However, from my experience, this often doesn't work well at all. Especially the RTag command seems to simply disregard the non-recursion directive. Even though it is far less elegant I settled for specifying the files explicitly because of this. > Alias module: > -------------- > ModuleReg -a RepoModule Module1/SubModule > > This will make it possible to have a shortcut to checkout several > modules not physically related in a single cvs co operation. All > aliased modules will be checked out separately as if the user had > given as many cvs co commands as there are modules in the list. Exactly. You seem to have missed one implicit goodie in this, though: The modules you specify to the right of the -a directive do not have to be physical modules. They could be *anything* that would be valid on the right hand side of a checkout command, i.e. also other virtual modules. Now you could do the following: ModuleFiles -d ModuleAmp RepoModule File1 File2 File3 ModuleAmp &AnotherModule &YetAnotherModule MyModule -a ModuleFiles ModuleAmp Checking out MyModule will produce exactly the same result as this: cvs checkout ModuleAmp ModuleFiles ... i.e. it will create the following structure: ModuleAmp << ./CVS/Repository will point to /RepoModule |- File1 |- File2 |- File3 |- AnotherModule << ./CVS/Repository will point to /AnotherModule | |- (subfolders and files) |- YetAnotherModule << ./CVS/Repository will point to /YetAnotherModule | |- (subfolders and files) ...which, if I'm not mistaken, is exactly what you were after, right? > Ampersand module: > ------------------ > ModuleReg &RepoModule &Module/SubModule > > This will act as the alias module, but it will first create the > ModuleReg folder, then check out the modules into that folder, thus > collecting the modules under a common top sandbox folder. The full > path will be used to the submodules. Note that for my above example I blindly assumed that this description was correct. I never used ampersand modules myself so far because from various past discussions here I was under the impression that they were unsafe to use. Thus I would probably have transscribed the above ampersand module like this instead: MyAnotherModule -d ModuleAmp/AnotherModule AnotherModule MyYetAnotherModule -d ModuleAmp/YetAnotherModule YetAnotherModule ModuleAmp -a MyAnotherModule MyYetAnotherModule Hope this helps. -- Oliver ---- ------------------ JID: ogiesen at jabber.org ICQ: 18777742 (http://wwp.icq.com/18777742)