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.
Thanks Erik. That's good info! :) Warren, Erik wrote: > We have the same situation as you do. > Dozens of individual projects but every one of those also makes use of fortran code common to other projects. There are at least two (yeah, I know understatement of the year) different ways to approach this situation. > > Approach 1 - Ampersand modules approach > Files used by multiple projects are located in a module we call util. > The util module is a sibling of all your project modules. > Use relative references when including files located in the util module in a project. > Lets assume that two of the projects you have are called aaa and bbb. > In the modules file you create an entry for each of these modules. > Create an alias module to specify the files located in the util module which are used by aaa called aaau. > Create an alias module to specify the files located in the util module which are used by bbb called bbbu. > An alternate to creating an alias module which specifies individual files would be to create an entry for the util module. > Finally create one ampersand module which includes both aaa and aaau then a second ampersand module which includes both bbb and bbbu. > When you use ampersand modules in this way you end up with many copies of the files in util in your sandbox. Be aware that when you update the files in the /util folder under projaaa those changes will not be visible in projbbb until you do an update on the file under projbbb. Therefore you may have several copies of the same file in different locations in your sandbox and each copy may be a different revision or tag. > > Using this approach your modules file would include: > aaa aaa > bbb bbb > aaau -a util/uuu1.code util/uuu2.code util/uuu3.code util/uuu5.code > bbbu -a util/uuu3.code util/uuu4.code util/uuu6.code > projaaa &aaa &aaau > projbbb &bbb &bbbu > > Or you might want to use the full util module in both projects and your modules file would include: > aaa aaa > bbb bbb > util util > projaaa &aaa &util > projbbb &bbb &util > > Your file structure when you check out the ampersand modules would be as follows: > > ==>/sandbox > ====>/projaaa > ======>/aaa > ======>/util > ====>/projbbb > ======>/bbb > ======>/util > > > > Approach 2 - Full repository checkout approach > This approach is the same as the first with one except that you don't make any ampersand modules and you keep all modules in your repository (or all the modules you are personally interested in) checked out to your sandbox all the time. > Files used by multiple projects are located in a module we call util. > The util module is a sibling of all your project modules. > Use relative references when including files located in the util module in a project. > Lets assume that two of the projects you have are called aaa and bbb. > In the modules file you create an entry for each of these modules and for the util module. > > Using this approach your modules file would include: > aaa aaa > bbb bbb > util util > > > Your file structure when you check out all modules would be as follows: > > ==>/sandbox > ====>/aaa > ====>/bbb > ====>/util > > Obviously there are advantages to each method as well as personal taste involved. > We use the second approach but we have a very small group and we do practically no branching whatsoever. I suspect that if you develop on branches regularly you will prefer to use the ampersand modules approach. Be aware that there has been a lot of traffic on this mailing list lately regarding the behavior of ampersand modules and I think Tony is considering a major overhaul of the code that handles modules. > > Erik W. Warren > Sr. Engineer - Flt. Ops. Engineering > Delta Air Lines > Dept. 088 > P.O. Box 20706 > Atlanta, GA 30320-6001 > Ph (404) 715-7229 > fax (404) 715-7202 > erik.warren at delta.com > > > > -----Original Message----- > From: user at domain.invalid [mailto:user at domain.invalid] > Sent: Wednesday, August 20, 2003 7:19 AM > To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > Subject: [cvsnt] Shared File Delima > > > Hello, > > This is a theory question...We are getting ready to migrate from VSS to > CVS (good move, I know) and we are wanting to rearrange our directory > structure. However, I'm having trouble finding good advise or examples > of what to do with shared files. For example: > > Project1, Project2 and Project3 all use the abc.code file (not a shared > DLL but an actual compile file). The abc.code file lives in a central > LIB directory. The projects each live in their own directories. What > is the best way to set this up in CVS? Should the directory structure > be rearranged? How are tagging and branching issues dealt with in this > scenario? > > If someone could point me to some examples of what others have done with > this, I would be most appreciative. > > TIA, > > Chris > > _______________________________________________ > cvsnt mailing list > cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs