Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Mon, 5 Feb 2018 14:55:43 -0600

On 02/05, Mark Rivers wrote:
> Hi Lewis,
> 
> > Or maybe Git submodules should be avoided.  It seems to me that
> > there are a number of headaches related to the use of submodules
> > in EPICS Base that come up from time to time; now it has come up
> > in areaDetector, and I suspect the headaches will continue simply
> > because submodules add complexity.  I think a Git repo containing
> > all of EPICS Base and another one containing all of areaDetector
> > would be much simpler to deal with.  I'm not a fan of submodules in
> > general.
> 
> I think you are mixing up 2 very separate issues:
> 
> 1) Having multiple repositories for EPICS base or areaDetector
> 2) Using git submodules to link those repositories
> 
> In my opinion it would be a terrible idea to go back to having
> areaDetector be a single git repository, which is how it was before
> R2-0.  By having multiple repositories we can independently release
> the core code (ADCore), the supporting libraries (ADSupport), and each
> detector (ADPilatus, etc.).  This is essential to producing timely
> releases.

Hi, Mark!

I can see what you're saying, but I must have never understood the
problems being faced or bought into them, and so I never understood
the benefit of submodules for areaDetector.  (I feel the same way for
EPICS Base, but to avoid muddling the discussion, I'm only talking about
areaDetector here.)

I don't understand why you want to separate out into multiple
repositories things that everyone will just turn around and combine
again.  Why not just leave them together?  Why is independently
releasing core code, supporting libraries, etc. a prerequisite of
producing timely releases?  Can't you just have a stable branch and a
development branch?  You make bug fixes on the stable branch and can
easily make new releases from that at any time.  You add features on the
development branch.  You declare a freeze on the development branch to
prepare for a new feature release, and then after ensuring everything
works, you make a new feature release.  Repeat.

> The use of git submodules in areaDetector is completely optional
> for the end-user.  They can simply checkout out each repository
> independently and manually arrange them in the following hierarchy
> 
> areaDetector
>   ADCore
>   ADSupport
>   ADPilatus
>   etc.

But that's a pain.  It would be way more convenient to just do "git
clone https://github.com/areaDetector/areaDetector.git"; (assuming the
one-repository approach) and know that I've got everything in the right
structure and ready to configure and build.

> The use of "git clone --recursive" is not required.  It is just a
> convenience if people want to check out lots of modules at the same
> time.

Maybe that's an area where I'm missing an understanding of the problem
as well.  I would just want to get the source code and build it.  If I
want to be selective and only build some things, I'd want to just change
a build configuration file to include or exclude certain things (like
the --enable-<option> and --disable-<option> options for an Autotools
configure script).

> In areaDetector only areaDetector repository and the ADCore repository
> are released synchronously, i.e. they have the same tags.  All other
> modules are released independently and have different tags.  So it
> really does not make sense to check out R3-2 at the top-level and
> expect it to update the submodules to some specific release (except
> ADCore).

Right, I understand that.  That's of course only because of the chosen
multiple-repositories approach, though.

Regards,

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System