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 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.