Experimental Physics and
Industrial Control System

Jeong Han Lee <[email protected]> · Mon, 5 Feb 2018 22:35:54 +0100

Hi Lewis,

 I agree with your view partly and I also **support** the current

EPICS base direction and areaDetector direction, even if git submodule

makes me crazy sometimes, but much less than svn did.

 Since I was introducing the git submodule at ESS, many people didn't

and I am sure do NOT like submodule now also, because of its complexity

and others thing.

 Yes, it is complicated, but it isn't more complicated than our life

is. :) And it has the big advantage from my naive view. One thing I can

say is that we don't need to hold, and track any epics community source

repository. Whenever, we need this, we can "sync" with the latest one,

and switch to tags, which we want to use in case we would like to deploy

to test environments and production environments. Still, we need to have

additional parent directory to hold them all.

 However, due to my lack of knowledge, and of my resources, tI cannot

use the full functionality of git submodule, but I use it within the

limited constraint. At ESS (European Spallation Source), we are using

the git submodule as "deployment", and git clone as "development". Still

these are very early concepts, however, it works fine so far. However,

our approach is to use git submodule as "link" to download the latest

one with ignoring git submodule hash (revision) now.

 My suggestion is not to use the vanilla repository of areaDetector,

but to build your own repository for your purpose via git submodule or

git clone. You can get the glimpse of how I am using git submodule and

clone via our github repository [1].

   HTH,

   Han

  ---

[1] https://github.com/icshwi/e3-base

On 02/05/2018 09:55 PM, J. Lewis Muir wrote:

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