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.
Nick Duane wrote: > Then at the repository you would have the following modules: > > repository\project1\serviceA > repository\project1\userlib1 > repository\project1\userlib2 > repository\project1\userlib3 > repository\project1\3rdParty\product1 > repository\project1\3rdParty\product2 > repository\project1\3rdParty\product3 > > and via the modules or modules2 you would define the following virtual > hierarchy: > > repository\project1\serviceA > repository\project1\serviceA\libs > repository\project1\serviceA\libs\userlib1 > repository\project1\serviceA\libs\userlib3 > repository\project1\serviceA\3rdParty > repository\project1\serviceA\3rdParty\product1 > repository\project1\serviceA\3rdParty\product2 > > Does any of this sound reasonable? If this is a reasonable thing to do the > one problem I see with it is that if you are working on several modules you > could have a lot of duplicated files contained in your working directory. Correct. Depends on how likely this is. If you check out the files to their repository locations, people make use of the code sharing between projects and download the shared code only once. The downside is that releasing a project doesn't release the shared code, and you have to do that manually. One thing that I think is worth looking into is to incorporate the checkout of shared code into build scripts, makefiles etc. I just started using this, and it makes some things easier. This gets rid of the problem with the dependencies: whenever a dev releases a shared module but still needs it for another project, it just gets checked out on the next build. Also, starting work on an already existing project with running a build is a good idea anyway (mostly). Gerhard