Re: AreaDetector repository inconsistent

[Jeong Han Lee <citadel.lee@gmail.com>]

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