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
Attachment:
signature.asc
Description: OpenPGP digital signature
- References:
- Re: AreaDetector repository inconsistent Ralph Lange
- Re: AreaDetector repository inconsistent Jörn Dreyer
- Re: AreaDetector repository inconsistent J. Lewis Muir
- RE: AreaDetector repository inconsistent Mark Rivers
- Re: AreaDetector repository inconsistent J. Lewis Muir
- RE: AreaDetector repository inconsistent Mark Rivers
- Re: AreaDetector repository inconsistent J. Lewis Muir
- RE: AreaDetector repository inconsistent Mark Rivers
- Re: AreaDetector repository inconsistent J. Lewis Muir
- Re: AreaDetector repository inconsistent Benjamin Franksen
- Re: AreaDetector repository inconsistent J. Lewis Muir
- Navigate by Date:
- Prev:
Re: cross-compiling for ppc64 with seq 2.1 and 2.2 Benjamin Franksen
- Next:
Re: AreaDetector repository inconsistent Mooney, Tim M.
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: AreaDetector repository inconsistent J. Lewis Muir
- Next:
Re: AreaDetector repository inconsistent Kevin Peterson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|