One of the things I like about the way I have Subversion set up is that I can have a single main repository with multiple projects. When I want to work on a project I can check out just that project. Like this
svn checkout http://.../main/ProductA
The guideline is simple, in regards to Git limits:
The idea is not to store everything in one giant git repo, but build a small repo as a main project, which will reference the right commits of other repos, each one representing a project or common component of its own.
This sounds similar to the "externals" support provided by subversion.
We tried this and found it extremely cumbersome to constantly update the version references in the externals since the projects are developed concurrently with dependencies on each other. Is there another option??
@Paul: yes, instead of updating the version from the main project, you either:
origintowards the same sub-repo being developed elsewhere: from there you just have to pull from that sub-repo the changes made elsewhere.
In both case, you have to not forget to commit the main project, to record the new configuration. No "external" property to update here. The all process is much more natural.
Honestly, this sounds like a real pain and anything that requires developers to do something manually each time is just going to be a regular source of bugs an maintenance.
I suppose I'll look into automating this with some scripts in the super project.
Honestly, you may have been right... that is until latest Git release 1.7.1.
git diff and
git status both learned to take into account submodules states even if executed from the main project.
You simply cannot miss submodule modification.
That being said: