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
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
When switching to a branch, it is always best to ensure a consistent state of submodules, e.g., for developers with full access:
git submodule update --init
SNL developers with only Gitlab-Ex access will need to turn off one submodule:
git submodule init git submodule deinit local git submodule update
External developers 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.
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.