| Author |
Message
|
| jsware |
 Posted: Tue Apr 21, 2015 11:42 am Post subject: Git Source Code Repository Layout |
 |
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
Hi,
I am interested in how others using git for broker code have organised their repository(ies).
We have over three hundred eclipse projects covering message flows, message sets, java compute node projects etc. etc. Some of this code is shared across MQSI apps (e.g. library projects). Some of these projects are related to each other (e.g. a msgflow project, mset project and Java compute node project). There's probably over 100 MQSI "apps" with significant code reuse and interconnectivity.
This is all stored in a single SVN repository under the standard trunk/branches/tags folder structure.
We have multiple delivery teams working on code. These teams work on different phases of a large programme of work (crossing multiple technologies). This means that say whilst features delivered in release X are still being worked on, teams begin work on release Y. Thus branching and merging code streams is important to deliver.
We have multiple branches under branches where generally the whole trunk is copied and releases are worked on. Periodically this code is merged back onto trunk (generally as stuff gets released) and then merged into other work streams and back onto the trunks - and so on.
We're considering switching to git which is viewed as having better distributed development capabilities and better branching and merging facilities. I'm not going to get into a debate on CVS vs SVN vs Git vs ANO
I'm wondering how other teams break up their code into repositories (or don't), their branching/merging strategy (or not). Do you have one single git repository with all your code in, have several repositories partitioned in some way, or down to small repositories with submodules etc to pull in shared code from library repositories. What is the basic rationale for this? Do you find this easy or difficult?
What do people think are good and bad practices for using git (lets stay away from using git = bad practice; not using git = good practice  )
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Apr 21, 2015 12:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
We used to use SVN and have a trunk, tag, branch per project.
You really need to look at what works best for you and what gives you the least work once it comes to merging trunk and branches...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Wed Apr 29, 2015 8:25 am Post subject: Re: Git Source Code Repository Layout |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
At our work place we are starting to build more and more flows and everything just gets dumped into SVN. So SVN simply becomes a way to backup the files.
I would like to move to GIT eventually. When doing Java Development GIT is far more superior than SVN in managing your java code, especially if you use Maven.
If we do move to GIT I will share my experiences on it here. However if I were to start migrating from SVN to GIT today I would simply create a GIT repo for each folder that contains a ".project" file in it. This is similar to how GIT is used in Java. I'm not sure this is the best approach but it seems most flexible in my opinion.
I'll report back in a few months if I end up doing this migration. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 29, 2015 11:53 am Post subject: Re: Git Source Code Repository Layout |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| sleepyjamie wrote: |
At our work place we are starting to build more and more flows and everything just gets dumped into SVN. So SVN simply becomes a way to backup the files.
I would like to move to GIT eventually. When doing Java Development GIT is far more superior than SVN in managing your java code, especially if you use Maven.
If we do move to GIT I will share my experiences on it here. However if I were to start migrating from SVN to GIT today I would simply create a GIT repo for each folder that contains a ".project" file in it. This is similar to how GIT is used in Java. I'm not sure this is the best approach but it seems most flexible in my opinion.
I'll report back in a few months if I end up doing this migration. |
I am thinking here about :externals and references.
So you might want to have a folder in GIT/svn above the workspace...
The workspace would then reference all the projects that are needed and draw them from their tags in svn/git...
But to everybody his /her own...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Wed Apr 29, 2015 11:55 am Post subject: Re: Git Source Code Repository Layout |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| Yeah that's another way. The problem is I don't have my workspace in the same location as my projects. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 29, 2015 11:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I would load the git extensions into Toolkit, or enable the ones that ship or etc...
Then I would point to a git repository, and share a project.
Then see what it looks like. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Wed Apr 29, 2015 12:03 pm Post subject: Re: Git Source Code Repository Layout |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
Sorry my bad. When you said workspace you meant the root folder of your projects.
Here is how I would do it
rootWorkspaceFolder/
....externalReference1/
......../.git
........SomeFile.esql
....externalReference2/
......../.git
........SomeFile.xsd
....SomeApplication/
......../.git
........MyFlow.msgflow
So in the above example I have 3 git repos. 2 which are external references / dependencies and the third is an application that depends on those two.
I think that makes sense on how I'm going to approach it.
The only issue with this is it would be a bit of a PITA to checkout all the dependencies you need in the same workspace. But this could be easily added to a README file or scripted using gradle. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 29, 2015 12:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
More like
some root
-- workspace with externals
|-- external1 reference for project1 creates folder project1 and brings in tag project1
|-- external2 reference for project2 creates folder project2 and brings in tag project2
|- etc...
So when you check out some root all your tags flow into the workspace when you update it. This is more of a build setup.
To work on a specific project you will still have to check it out instead of "bringing it in" ....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Wed Apr 29, 2015 12:14 pm Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| Actually. I shouldnt be using the term checkout. Should be "clone" |
|
| Back to top |
|
|
| jsware |
| Posted: Thu Apr 30, 2015 9:44 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
My thinking is to have a repository per MQSI Application - this might involve multiple eclipse projects (msgflow, java, msgset etc).
All this in the same git repository.
Then use git submodules for the common libraries that you want to pull in which are in a common modules repository.
Does mean you might have to clone multiple repositories into a workspace.
I'm thinking somewhere in between - say by business area/unit - 1 repo per each with multiple apps and multiple/multiple eclipse projects in the same one. This would then group related MQSI Apps together.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Tue Dec 08, 2015 8:54 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
After several months of using GIT with IIB we have chosen the following stategy:
- 1 GIT repo per MQSI application
- Any common code (e.g. libraries, message sets, etc.) are put into submodules which are shared across multiple applications.
This works really well for us because especially in our DevOps environment where on every commit, the BAR file is built, versioned, and placed into integration/test environment for our QA folks to run regression tests on.
Also the 1 git repo per application makes it easy to track commits. |
|
| Back to top |
|
|
|
|
