Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 9 Feb 2018 19:09:20 +0100

On 02/08/2018 06:35 PM, J. Lewis Muir wrote:
> On 02/07, Benjamin Franksen wrote:
>> For us, thanks to sumo [1], rebuilding EPICS modules together with all
>> dependencies (those that are in use in your application) is mostly
>> automatic, greatly relieving the pain of upgrading single modules even
>> if they are deep down in the dependency tree (like e.g. asyn or even
>> EPICS base itself).
> 
> Thanks for sharing about sumo!  What do you do when you need to fix a
> bug in, or change, a module? That is, the fix has not been committed
> to the module or a new release has not been made, or you are carrying a
> patch specific to your site that upstream does not accept?

We have a long tradition of importing external modules into our version
control system (we use darcs, mostly). It is a good idea to keep a
vendor branch where only the original tar.gz files (or occasionally
official external patches) are imported/applied. When I make local
changes, I create a release branch, tagging HZB-internal sub-releases on
that branch. For instance, in the application I am working on currently
I have:

> grep ASYN configure/MODULES
        "ASYN:R4-30-bessy2",
> grep ASYN configure/RELEASE
ASYN=/srv/csr/Epics/sumo/build/ASYN/R4-30-bessy2+MLS-086

The R4-30-bessy2 version has a few patches I made which have already
been merged into upstream. The MLS-086 is a build number assigned by
sumo to distinguish different builds of the same module version.

You can do similar things with git or any other modern VCS. With git you
could mirror the upstream repo and add your local modifications on local
branches, but that might require advanced levels of git-fu, YMMV.

> Does sumo support applying a list of patch files?

Yes. Very handy sometimes, but I warn against over-using it. Version
control is vastly superior if you want to look at the sources and
understand/view each change separately.

> Or maybe sumo expects you to
> host the modified module somewhere (e.g., a forked GitHub repo with your
> changes)?

It doesn't force a particular style on you. It supports darcs,
mercurial, and git if your prefer VC, but also tar balls. You can put
your changes on github, or (as we traditionally do) maintain repos on
your own machine, or forgo version control and only use tar balls.
Additional patch files can be applied in any case.

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." ― Scott Adams

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System