# Projects within projects 3 messages from 2009-10-29 to 2009-10-29. Participants: Nick Colgan, Avery Pennarun, Bill Lear. Thread: https://gitlist.dev/t/21425 ## Nick Colgan, 2009-10-29 18:40 Subject: Projects within projects Message-ID: URL: https://gitlist.dev/e/ab1d51700910291140ncd80027j4ee9a30637d7bc40%40mail.gmail.com ``` I'm currently working on a project made up of parts that could each be considered a project in itself. I plan on using redmine or trac to manage the project. Now I'm trying to figure out how to manage the repo(s) for the project. These are the current options I have in mind: 1. Create a separate repository for each sub-project and manage each separately in redmine (separate bug tracker, wiki, etc.) 2. Create a single repository with a subdirectory for each sub-project. 3. Use git submodules or subversion externals to combine options 1 and 2 by creating a separate repo for each sub-project, then creating a master repo with subdirectory for each sub-project that imports from their respective repositories. What's the best way to handle this situation? Are git submodules and/or svn externals sufficiently capable of dealing with this? Thanks, nic. ``` ## Avery Pennarun, 2009-10-29 18:56 Subject: Re: Projects within projects Message-ID: <32541b130910291156w693a188dv6dfd0d39a506d145@mail.gmail.com> URL: https://gitlist.dev/e/32541b130910291156w693a188dv6dfd0d39a506d145%40mail.gmail.com In-Reply-To: ``` On Thu, Oct 29, 2009 at 2:40 PM, Nick Colgan wrote: > These are the current options I have in mind: > > 1. Create a separate repository for each sub-project and manage each > separately in redmine (separate bug tracker, wiki, etc.) > > 2. Create a single repository with a subdirectory for each sub-project. > > 3. Use git submodules or subversion externals to combine options 1 and 2 > by creating a separate repo for each sub-project, then creating a master > repo with subdirectory for each sub-project that imports from their > respective repositories. > > What's the best way to handle this situation? Are git submodules and/or > svn externals sufficiently capable of dealing with this? Every way has tradeoffs. I'd suggest first thinking about whether these supposedly independent projects are *really* going to be independent or not. If they're unlikely to ever be reused - or they won't be for a long time - #2 is by far the easiest choice. If you choose #2 and then choose to split the repo later, you can use git-subtree (http://github.com/apenwarr/git-subtree) to split it easily, so there's little sacrifice in using #2 at first and changing your mind later. If you choose #3, that's exactly that git-submodule and svn:externals are for, and it seems to work okay for a lot of people. It's more work though, since you have to be careful to isolate commits between one project and another, etc. Personally I prefer to use git-subtree for this too, but it's a matter of preference. Have fun, Avery ``` ## Bill Lear, 2009-10-29 19:33 Subject: Re: Projects within projects Message-ID: <19177.60959.457301.349805@lisa.zopyra.com> URL: https://gitlist.dev/e/19177.60959.457301.349805%40lisa.zopyra.com In-Reply-To: ``` On Thursday, October 29, 2009 at 14:40:36 (-0400) Nick Colgan writes: >I'm currently working on a project made up of parts that could each be >considered a project in itself. I plan on using redmine or trac to >manage the project. Now I'm trying to figure out how to manage the >repo(s) for the project. > >These are the current options I have in mind: > >1. Create a separate repository for each sub-project and manage each >separately in redmine (separate bug tracker, wiki, etc.) > >2. Create a single repository with a subdirectory for each sub-project. > >3. Use git submodules or subversion externals to combine options 1 and 2 >by creating a separate repo for each sub-project, then creating a master >repo with subdirectory for each sub-project that imports from their >respective repositories. > >What's the best way to handle this situation? Are git submodules and/or >svn externals sufficiently capable of dealing with this? Let me give you an example of #3. I write a fair amount in C++ and have written a reasonably sophisticated makefile system to allow me to create a new directory in a project, put files in it, link in a master makefile, cd into the directory and type 'make' and have things build without me having to edit the makefile --- I don't want to write makefile rules, etc., I want to write C++ (fill in the blank here). It basically relies on naming conventions, but it suits me perfectly. If I name a file test_*.cc or t_*.cc, or tc_*.cc, it is a unit test, if I name it m_*.cc, or main_*.cc, it is a main program. Library inter-dependencies are easy to set up in a central way, blah blah blah --- the details are not terribly important. In any case, I created a new project to work on some "real-time" financial trading algorithms. I did this by creating a new repository into which I added a src directory, under which were several other directories of source code. At the top level of the new repo, I added a git submodule 'mk' that contains my makefile system. I then linked the master makefile to my source directory makefile and was off compiling easily. In this case, I do absolutely reuse my makefile system across multiple projects. It is 100% orthogonal, and I have so far found it to be very useful to use git submodules. I imagine also if you are building software that is 100% orthogonal that you would like to reuse in many projects, git submobules is the way to go. I read the Git Submodule Tutorial on the Git Wiki and found myself able to use submodules very easily after that. bill ```