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 firstname.lastname@example.org.
> What's the concept of Modules? The classic, simplistic answer is that a module is anything that you can checkout (using cvs checkout blah). This is not very helpful, though, since you can checkout each single file from any module structure, if you choose (say: cvs checkout thisApplication/thatComponent/design/readme.before.everything.else.txt) The more complex answer is that a module in Configuration Management and Revision Controlling is whatever you say, i.e. your configuration needs define what makes up a module and what doesn't. To make things even more confusing, modules can contain other modules. It is not really some physical or logical entity built into CVS. Your decision on what constitutes a module will usually depend on various considerations, including: - which files need to be worked on together? One example are all files required to compile a software module (makefile, source files, ...), hence the name. - which files to you want to reuse in other applications? - which files should be accessible by certain persons only? (developers, testers, technical writers, ...) So, in your example, > I am working on a project called cframework so would > the folder c:\CVS\cframework be a module or the root > for the repository. Or is it meant that for example > c:\CVS\cframework\code is the directory for the module > code, where all the code is stored in and > c:\CVS\cframework\manual would be the one for the > module manual? The answer would be that all three are modules (building a hierarchy of related modules). In addition, you might identify additional modules, especially inside c:\CVS\cframework\code, according to other criteria. Hope that helps. Michael