On 2014-11-19 07:27, Alf Birger Rustad wrote:
Hello everybody,
I am guilty of creating yet another repository in opm. Please provide
feed-back if you like it or not. We can rename it or even delete it.
It is called opm-utilities and currently hosts the python script
summaryplot. Right now it is afaik the only tool we have to plot
results from summary files. The author, Håvard Berland, is happy
about contributing it.
The thought is that we have this repo for such handy utilities that
does not belong in any other repo. Thoughts are welcome.
Cheers,
Alf
Honestly, I don't think it's that good an idea to have separate
repositories at all, and especially not to this extent. Let me explain:
1. Some changes actually goes across multiple repositories because of
inter-module dependencies. This mandates book-keeping and
patch-references between completely independent units and generates more
work, more points of failure and generally makes our lives harder.
2. It makes "just building the project" harder, because of implicit
dependencies and builder order and other shenanigans. Ideally we should
be able to git checkout; mkdir build; cmake; make; in order to get a
working binary.
3. Increased maintenance cost of the build system, cmake modules
especially. A relevant example: in order to test petsc as a backend
solver for the upscale-benchmark I had to:
#1: implement the FindPetsc.cmake in opm-core
#2: copy this FindPetsc.cmake (and other modifications) to opm-porsol
(IncompFlowSolverHybrid)
#3: copy this FindPetsc.cmake and other changes to opm-benchmark
#4: compile & pray I didn't miss anything.
This shouldn't be necessary and is a recipe for "lagging updates" in
various repositories.
This is what I propose instead:
Remove the repositories all-together and replace with a single opm repo.
We maintain the same structure, but with branches instead. The nature of
git makes this basically indistinguishable from separate repos. We then
implement a master "next-release" branch that we merge all the other
branches into, and a series of other "module branches", e.g. opm-core,
opm-upscaler, opm-porsol etc. This is much easier to deal with and, in
my opinion, a superiour model. It gives the same module distinction as
earlier, but it actually manages dependencies in a reasonable manner and
makes inter-module changes easier. We already have previous release tags
and branches, and this isn't unreasonable to have in the future, but now
it will possibly even be simpler because "releases" will now be across
all modules.
I cannot think of any downsides to doing it this way, but I'd appreciate
some discussion on this.
For reference, the linux kernel, which is a much larger project than
opm, only use one repo.
- Jørgen
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
