Cloning the Dakota Repository
The Dakota repository is separated into public and private meta-packages. The core or top-level repository uses git submodules to pull most components from public servers and select SNL-specific compoents from private servers to create a complete Dakota checkout. A full clone of Dakota (including submodules) can be checked out by development team members with full access with the single command:
git clone --recursive software.sandia.gov:/git/dakota
Developers without full access will need to instead
git clone software.sandia.gov:/git/dakota
See notes below for caveats on submodules for external or SNL developers without full access.
Read-only anonymous access: To access the Dakota source code without authentication, instead use
git clone https://software.sandia.gov/git/dakota
Branch Checkout
Determine Branch: After obtaining the Dakota code, you will automatically be on the "master" branch. This branch is intended to be a stable, release-quality branch that undergoes more extensive testing. It is not possible to commit directly to this branch. If you intend to make changes, the "devel" branch (or a topic branch) should be used.
cd dakota git checkout devel
Syncing Submodules
When switching to a branch, it is always best to ensure a consistent state of submodules, e.g., for SNL Dakota contributors with full access:
git submodule update --init
Otherwise, SNL Dakota contributors with access to Dakota's gitlab-ex repos will need to turn off one submodule:
git submodule init git submodule deinit local git submodule update
Otherwise, external contributors and anonymous cloners can only access the software.sandia.gov submodules, so may instead opt for only initializing the submodules they have access to:
git submodule init packages/external git submodule init packages/pecos git submodule init packages/surfpack git submodule update
Or alternately deinit-ing the others (packages/local/DOT, packages/local/NLPQL, packages/local/NPSOL, local).
With any of these approaches, subsequent submodule operations such as 'submodule update' can then be performed automatically over the set of initialized modules.
Note that top-level Dakota refers to the three software.sandia.gov submodules using relative paths, so Git should by default clone them using the same protocol as the top-level Dakota clone (for top-level HTTPS clone, submodules should pull via HTTPS). However, in some cases Git will want to switch to or default to another protocol, e.g., SSH instead of HTTPS. For these cases it may be necessary to edit .gitmodules to have absolute paths to the submodules, e.g., https://software.sandia.gov/git/pecos, and then run git submodule sync. Or use a Git insteadOf directive in your Git config for these repos.
Master Branch Integration
Updating the "master" branch with changes to the "devel" branch: To preseve the stable quality of the "master" branch, a nightly Jenkins job performs a more extensive set of builds and testing on the "devel" branch followed by automated updating of "master" after successful completion.