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.