On 2014-11-19 11:11, Bård Skaflestad wrote:
On 2014-11-19 17:41, Jørgen Kvalsvik wrote:
On 2014-11-19 07:27, Alf Birger Rustad wrote:
Hello everybody,
I am guilty of creating yet another repository in opm. [...]
Honestly, I don't think it's that good an idea to have separate
repositories at all [...]
Noted.
3. Increased maintenance cost of the build system, cmake modules
especially.
http://rolk.github.io/2013/09/23/build-system-sync/
Wouldn't it be better if this wasn't necessary?
So, you're proposing to undo the (more or less) careful separation of
responsibilities of user-facing features into autonomous but related
modules for the sake of build-time convenience for the *very* few OPM
developers? That won't happen as long as I have any say in the
matter
If you want to look at it that way, sure, but it's not really what I'm
suggesting. The separation will still exist, but the unit will be a
branch and not a repository. Since branches can be just as independent
as repositories it wouldn't really change anything except for
convenience in the right places.
Were it not for the fact that opm-core depends on opm-parser I would
be able to download "only" opm-core and get access to powerful grid
processing routines, an implementation of mimetic discretisations
(somewhat languishing but nevertheless working), partial support for
the multi-scale mixed finite-element method, time-of-flight solvers
based on the reordering technique, explicit and implicit solvers for
two-phase incompressible transport problems. In essence, fundamental
tools for doing simple calculations in porous media applications.
git clone -b opm-core github.com:opm-project
If we renege that ability in order to manufacture a single monolithic
package for black-oil applications, albeit with interesting physical
properties such as polymer and/or thermal effects, then the project
has lost its way.
I didn't suggest that at all.
[...]
For reference, the Linux kernel, which is a much larger project than
opm, only use one repo.
Clients are expected to use the entire Linux tree as whole when doing
anything with the Linux sources. That assumption doesn't hold in the
case of OPM.
The argument was mostly related to size and code management.
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
