I know there are multiple posts on similar problems, so please be kind with me. I am asking for suggestions I have not thought of and for good advice.
I have a java "project" that is structured in a server-client pattern.
There are some classes that are common to both parts but most of it is either server (backend and control logic) or client (GUI). To not write one monolithic application (where the client depends on
JDBC jars) I decided to split the project into multiple eclipse projects:
proj_test there is some code to test parts of the client/server. I setup eclipse such that both server and client depend on the common module.
Now I use git to manage all these eclipse projects.
My first thought was to manage all parts in separate repos as suggested by git.
But I have the problem that I loose the relation of the different commits: Any modification in the
proj_common will typically reflect some data type modification. This makes the new version incompatible with old commit in the other projects.
I then thought of several possibilities:
- Using of
- Using of
- Using of a single git repository that contains the modules together
- Using different repositories and adding regularly tags to the commits to keep track of the relations
The solution 1 has the problem that it is quite heavy to maintain. Especially if you want to check in multiple small modifications you have to go multiple times "around the folders" to
commit and then pack it all in the main repository up.
subtree method might work well as far as I have read with a bunch of scripts to manage the git calls. The main disadvantage is that
subtree fits perfectly if most work is done in the main repository and updates to the imported repos happen occasionally. If the updates happen merely in the subprojects the history of the main projects gets quite crumpled.
On branching it might get complicated.
The solution number 3 is my favourite solution so far as everything is kept tight and branching is done without any problem.
The solution 4 is mainly what is done now, but no tag have been created yet (pre-alpha, thus no sense in creating tags). As the project grows this might get also very nasty and error-prone.
What would you suggest? One of the given solutions or did I miss the one perfect solution?
I have found the following related posts: a, b, c and d. Unfortunately the big picture is not clear. In a (second answer!) and d the advice tends towards multiple repositories in different files. But they do not explicitly state how to manage the relationship of the different commits. That is you cannot go for the running configuration at Jan 10th 2013 for example without looking at the history explicitly for all subprojects. In b solution 3 is suggested. In c a comparision is made. They first had something like multiple manually managed projects but then migrated to solution 3.
In all these Q&As the first two solutions were at most mentioned but not suggested by the answering persons.
In the net you can find much about
git submodule that tells you that you get quite much overhead by it (e.g. here or here).
The problem is (as far as I can see) that in practice I will have not only one project with some reference to one or more libraries.
In this case (hopefully) the library would not change regularly and the coding takes place in the "main" repository.
In this case all the advances solutions (
submodules, ...) might be very useful.
In my case on the contrary I have only a dummy master repository that holds the four subprojects in sync. These subprojects themselves are under high development. So it is a critical part that the contribution to the different online (sub)projects is straight forward. Not much additional magic with git.
In another site they suggest solution 1 but I am unsure what their main development goal is: The main repository or the imported library.
I want to avoid getting into trouble and later have to migrate to another system. Thus I ask for advice of somebody who might have done similar things.