Re: Understanding the GIT organization and workflow for EPICS 7

[Bruce Hill <bhill@slac.stanford.edu>]

I'm still trying to figure out a good workflow for introducing local
build changes and other local commits.    I'm finding the first step
is to create your own local branch.
git co core/master
git co -b core/slac-master

Once this is done you at least have a branch where you can save
and manage local commits without making commits on core/master
that you'll later regret when you want to pull the latest core/master updates.

I also modified my core/slac-branch .gitmodules file to list our SLAC repos,
although I think that can also be done by changing your config settings
submodule.modules/pvAccess.url, etc .   Still experimenting w/ this and
how to control which version of each submodule is checked out, as we
often would want to build the latest tagged release of pvAccess or pvData
instead of their master branch.

I haven't figured out how to checkout a tagged module in one step from TOP, but
these steps work for me so far.
pushd modules/pvAccess
git co R6.0.0-0.3.0
popd
git add modules/pvAccess

# Commit changes if you want to checkout and/or update core/master
git ci -m "Updated pvAccess to R6.0.0-0.3.0"
git co core/master
git pull
git submodule update


Cheers,
- Bruce

On 02/23/2018 02:08 AM, Ralph Lange wrote:

On Fri, Feb 23, 2018 at 10:36 AM, Dirk Zimoch <dirk.zimoch@psi.ch> wrote:

Also it should be clarified where new developments take place. This is still a bit unclear to me. Should any new features be developed on the 3.15 and 3.16 branches or only on the master (EPICS 7) branch?

This has not changed, and is mostly unrelated to the recent repository and structure changes:

Any feature should be developed on the branch that it is targeted at.

All applicable changes and fixes are merged up regularly (in the direction of increasing branch numbers).

Which release series a specific feature is targeted at - that is a design decision and depends on a number of factors. In general, the more stable a release series, the less new features it should get.

Currently, a new feature for 3.14 would probably not be accepted, for 3.15 it would need a very good justification and thorough tests. 3.16 would get features if they are closely related to other featured introduced in that release series. Anything else should probably go on the master branches.

Good practice is to use this mailing list for a discussion in non-trivial cases.

Cheers,
~Ralph

-- 
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA  94025