Re: Understanding the GIT organization and workflow for EPICS 7

["Williams Jr., Ernest L." <ernesto@slac.stanford.edu>]

Ernest Williams
Dept. Head, Advanced Control Systems
Advanced Instrumentation Research, Technology Innovation Directorate
SLAC National Laboratory, Stanford University

---

From: core-talk-bounces@aps.anl.gov <core-talk-bounces@aps.anl.gov> on behalf of Andrew Johnson <anj@aps.anl.gov>
Sent: Thursday, February 22, 2018 1:51 PM
To: core-talk@aps.anl.gov
Subject: Re: Understanding the GIT organization and workflow for EPICS 7

 

Hi Ernest,

On 02/22/2018 12:16 AM, Williams Jr., Ernest L. wrote:
> We are trying to understand how to work with updating our EPICS 7
> release here at SLAC.
>
> So, when updates or patches are applied what is the process for us to
> update and build?

We can't write your processes or procedures for you, although I believe
you have access to Michael Davidsaver who could help you develop such
things. You could also fund him to help work on (and potentially speed
up) the documented process in our Release Checklist
  https://epics.anl.gov/base/R7-0/1-docs/ReleaseChecklist.html
to more closely match your needs — I would be open to making more
frequent bug-fix releases of EPICS 7 as long as they can be automated.
The current manual process is far too slow and cumbersome to do every
time we introduce a bug-fix.

>> Agree completely here.


> A few questions:
>
>  1. Will the EPICS BASE associated with EPICS 7 be called 3.17, when
>     ready production release?

No, the development branch of EPICS Base is now 7.x (but it has a number
of submodules that all have their own release version numbers). There is
no separate Base-like thing that exists without all the PVA submodules;
we are considering re-combining the core modules back into a single git
branch, but we will keep the new modules/* structure.

There is (was) an internal 3.17 branch that contains many of the new
features that were added to Base after the release of 3.16 (features
which will not appear in any 3.16.x release), but that 3.17 branch isn't
officially published. I sometimes use it when merging bug fixes up from
the older branches so you might see the name in commit log messages, but
that's just for my convenience.

>> Sounds good, so as a consumer of EPICS 7; I will focus on

>> the 7.x development branch.


>            I learned from Michael that 3.16 is different from the HEAD
> (i.e. core/master)

Very different. In addition to the extra features the pcas and gdd were
unbundled; Ralph moved libcom, ca and the database into separate
submodules, which were all reorganized internally to separate test
program sources from the sources of the software; we added build rules
for submodules, and moved some things around inside the build system to
localize them to the submodule to which they applied; the main PVA
modules were added, and some boost headers needed by pvData to build on
vxWorks was added to libCom.

>       2. What is the key feature set planned for the "HEAD"?

My crystal ball is on the fritz at the moment, but we will probably be
introducing new link types, improving documentation and adding other
stuff as it gets developed. What new features would you like to see (and
be willing to help develop, either with money or manpower)?

>> We are working on a list now.  Some items you already have on your list.

>> We may consider adding manpower/funding to accelerate its development/implementation schedule

>       3. How do I stay in synch with the HEAD (i.e.  git pull) ?

To update your tree to the very latest commit from all the submodule
repositories, you can either do

  git pull
  git submodule update --remote

or

  git pull
  .ci/checkout-modules.sh

The latter script first checks out each of the submodules onto its
development branch (the different submodules can have different branch
names, which is why the script is useful) and it then does a git pull to
get the latest version on that branch. After running that script once
you can later update any individual submodule by doing for example

  cd modules/ca
  git pull

You should also do a git pull at the top level to keep that up to date.

>> Awesome !!  I will definitely use your script.


>       4. Looks like "ca", "core", "database", and "libcom"  are
> git submodules?

core/master is a branch for the top-level module, which also contains
the build rules and general-purpose Perl programs used at build-time.
That branch also specifies the submodules that belong within it; libcom,
ca and database are those derived from the old Base, and we also added
the PVA modules (which are now just as much part of EPICS 7 as those
that came from Base itself).

> So, finally can I have an example which demonstrates how to update
> modules/ca ?
>
> The current state is:
>
> [ernesto@localhost ca]$ git branch
> * (HEAD detached at eb683aa8a)
>  core/master
> [ernesto@localhost ca]$
>
>
> To stay in synch; is this where I should:
>
> (a) git checkout master
> (b) git pull

No, the code in modules/ca is found on a branch named ca/master, so
there you would need to do

  cd modules/ca
  git checkout ca/master
  git pull

That's why I wrote the checkout-modules.sh script, so you don't need to
know what all the branch names are.

HTH,

>> Thanks, Andrew this does the trick for me.  👍


- Andrew

--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon