Re: [oll-user] Repository organization

[Joseph R. W. <jos...@we...>]

On 04/05/2013 05:01 PM, Urs Liska wrote:
> Basically I fully agree with that POV, as the sub-projects really are quite independent conceptually, and I agree that the interdependence of the current design is based on my perception of the 'whole' which is far from being carved in stone.

The other key reason to separate is about maintenance and commit right
bottlenecks.  By having everything in one big repo, you wind up either having to
give lots of people commit rights (not very safe), or you have to channel all
contributions through a few people.

By splitting things into separately-versioned projects, you can have different
people maintaining different parts, so a small number of committers on a
per-project basis but a large number of people involved overall.

> However, I'm still somewhat insecure about how the submodule approach is actually manageable.
>  From trying to understand the docs and reading blog posts I have two questions:
> 
> 1)
> A submodule isn't just a Git repository living in a subdirectory. Instead, a submodule points to another remote repository, so this seems to mean that we have (e.g.) lilyglyphs as a subdirectory/submodule within openlilylib _and_ as  standalone repository.
> I understand this set-up for the usual examples of a third-party library, but I don't really see how this is natural for our case.
> 
> 2)
> I have read that it is comparably 'simple' to get the repo/submodule constellation out of sync and even corrupted (if one part points to a commit that the other part hasn't pushed etc.).
> How complicated does a working policy have to prevent this? And how complicated is it to recover from such situations?
> Instead of an explanation I would also accept statements like "I know this works smoothly, and you'll see it when it is running".

Can't speak to (2) as I have never encountered it.  But if you are concerned,
the simplest way is just to give up the idea of one-repo-to-rule-them-all and
have a few different repositories to cover different parts of the project.

It's zero added complexity for users of the project, as one can always bundle
everything together in one big .tar.gz file for user download; it adds some
complexity for developers/contributors but also reduces complexity in other ways.

So, I would start by modularizing the project appropriately into different repos
without worrying about submodules, and think about introducing them later if
that seems to be necessary.