The Dakota repository is separated into public and private (local) meta-packages, which use git submodules to pull components from public servers and from private servers to create a complete Dakota checkout. The public portion of Dakota (including submodules) can be checked out by development team members with the single command:

git clone --recursive software.sandia.gov:/git/dakota

Read-only anonymous access: To access the Dakota source code without authentication, instead use git clone https://software.sandia.gov/git/dakota (As of 2020-01-23, Dakota's submodules are specified with relative URLs and you should not need to edit dakota/.gitmodules for https.)

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.  When switching to this branch (or any branch) it is always best to ensure a consistent state of submodules and private/local content, e.g.

cd dakota
git checkout devel
git submodule update --init

Private/local: To obtain content from the private (local) servers, you must have appropriate access. The following helper script can be invoked from the top level of the dakota source directory:

cd dakota
./sync.local-git.sh

At this point, the project will reflect the content of either the "master" branch or the "devel" branch of Dakota along with corresponding submodule versions.

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.