coapp-developers team mailing list archive

[Philip Allison <mangobrain@xxxxxxxxxxxxxx>]

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.