Projects within projects

Projects within projects

[Nick Colgan]

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.

Re: Projects within projects

[Avery Pennarun]

On Thu, Oct 29, 2009 at 2:40 PM, Nick Colgan <nick.colgan@gmail.com> 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

Re: Projects within projects

[Bill Lear]

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