I did wonder about the layout after I first checked out. Reminded me of when we tried to use git submodules at work - an experiment which failed quite badly and put me off the idea until someone can convince me otherwise. FWIW, we're trialling a different layout for another multi-repository project - I can't remember the approach exactly, since I'm not currently assigned to said project, but it's something along the lines of:
/usr/src/bigfreakinproject/repositories/main.git/ ^ Working copy of the "core" repository, containing common code, along with scripts for preparing the host for build (quite a specialised process in this case) and "for-each" scripts to ease management of submodules /usr/src/bigfreakinproject/repositories/subprojA.git/ /usr/src/bigfreakinproject/repositories/subprojB.git/ /usr/src/bigfreakinproject/repositories/subprojC.git/ ^ Working copies of related projects, as checked out either by hand, or by scripts within main. Checked out side-by-side with the working copy of main, not as subdirectories of it. /usr/src/bigfreakinproject/build/.../modules/A/ /usr/src/bigfreakinproject/build/.../modules/B/ /usr/src/bigfreakinproject/build/.../modules/C/ /usr/src/bigfreakinproject/build/target/bigfreakinproject-ABC.tar.gz ^ Build-preparation script inside main copies/updates necessary infrastructure on the host, being careful not to stray outside /usr/src/bigfreakinproject, with the end result that one can essentially cd into /usr/src/bigfreakinproject and run "make". No generated files ever end up in the /u/s/b/repositories tree, just version-controlled stuff. I suppose time will tell whether or not we run into large enough problems to make it worth rethinking coapp's source layout, but it does make me a bit nervous. _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
