[clean-energy]

Hello,

I would like to deal with the following situation:

We are a Team of 6 people developing in OpenFOAM.

Is it possible to run a git server with a clone of the official release for our development team.

In other words we would like to have a server which syncs automatically with the official git repos of OpenFOAM where we can commit our changes to.

After a long internet search I am not sure what the best way would be. Is it possible to have a OpenFOAM git fork on our server which has still a link to the official release.

Thank you very much in advance!

[olesen]

Originally Posted by clean-energy

...
In other words we would like to have a server which syncs automatically with the official git repos of OpenFOAM where we can commit our changes to.

You could easily automate a 'git fetch' with simple cron job on your local server. However, merging in the upstream 'master' branch should be left as a manual operation. Your local team would work on a separate branch and periodically merge the changes from 'master'. This is what I meant here (http://olesenm.github.com/2009/11/12...nFOAM-and-git/) about never working on tracked branches.

[eelcovv]

Hi Mark,

Thanks for the information you have been putting on git and openfoam so far.

I am dealing with the same situation : I want to add solvers and libs to the OF distribution and share it with my colleagues.

There are two scenarios
1) make a new company repository containing the src, application, tutorials and run directory and add all the new stuff here. The the new stuff get in its own directory

2) make a new branch in the Openfoan 2.2.x directory and add all the changes in this branch. So all the changes are done in the orirginal OpenFOAM-2.*.x directory

I think you recommend scenario 2 and I see the advantage: you can merge the new updates from the OF 2.2.x into you own branch.

I have one concern: when compiling the new (own) branch, all executables of sources and libraries that have been change will appear with the same name in the lib and bin directory, unless you modify these names explicitly in the Make file. How do you deal with that. Do you make new lib names of libraries you have modified, or do you keep the original names such that all the other OF solvers can benefit (hopefully) from the changes.

I am still thinking of best work flow to deal with this.

Hopefully you can give some hints.

Regards
Eelco

[olesen]

Originally Posted by eelcovv

Hi Mark,

...
I have one concern: when compiling the new (own) branch, all executables of sources and libraries that have been change will appear with the same name in the lib and bin directory, unless you modify these names explicitly in the Make file. How do you deal with that. Do you make new lib names of libraries you have modified, or do you keep the original names such that all the other OF solvers can benefit (hopefully) from the changes.

If you are only maintaining your own set of solvers/libs without needing to adjust the OPENFOAM source code itself, you don't need to work in the main OPENFOAM directory itself. Instead, just create/compile your applications as usual (eg, in your home directory) and then "publish" to a shared site location. You can either use the default WM_PROJECT_INST_DIR/site or place it elsewhere and set the WM_PROJECT_SITE env variable accordingly.

By "publishing" the applications and templates, I simply mean using a script to sync from your build directory to the "site" location. This is the workflow that we are now using for our standard applications. Of course, if you need to make changes to the OPENFOAM sources themselves, you'll still have to do this as previously described.

/mark

[eelcovv]

Mark,

Thanks for the reply. After some thoughts about it I have opted for the hybrid approach just as you recommend right now.

The standalone new solvers I have put in my own OF directory under eelco-2.2.x and put this into a repository which my colleagues can approach.

Next to that I want to make small modifications to the OF libraries in order to included more functionality I need (especially in the lagrangian lib). This I do in the OpenFOAM-2.2.x on a new branch just as you have described on you blog. This allows me to keep track of the updates of the original OF distribution and easily merge them to my own branch. This modified OF-2.2x branch I store in a separate repository.

So far the hybrid approach works for me. Thanks for the hints and the useful info you have put on your blog!

Regards
Eelco