Best Practices for Reproducible Research

Session 3

Ingmar Steiner

2017-05-17

SCM Assignment Review

Subversion

Presentation/Demo (Iona)

Mercurial

Presentation/Demo (Eran, Katja)

Fossil

Presentation/Demo (Iliana)

Git

SCM of choice for the remainder of this course.

SCM Workflows in Depth

Clones

For distributed SCM, entire repositories can be cloned, i.e., duplicated.

Benefits

  • synchronize across multiple devices
  • collaborate
  • backup
  • agile development (nested repos, composite builds)
  • …

Remotes

  • An SCM repository can have one or more remotes.

  • Commits can be fetched from, or pushed to, the remotes.

Some of the remotes can be clones or the origin from where the repo itself was cloned.

Repository network topologies

Central hub
Central hub
Fully connected
Fully connected
Daisy chain
Daisy chain
Fork in the cloud
Fork in the cloud
Hub in the cloud
Hub in the cloud

SCM repository hosting

  • Cloud based
  • Forking workflow (fork = cloud-side clone)
  • Pull/merge requests
  • Examples: GitHub, Bitbucket, GitLab, etc.
  • Access control
  • Public vs. private repositories

Back to the real-world example

Recap
Recap

Cloud-based, hub-forking collaboration

  • Bob sets up main upstream repo in the cloud
  • Bob, Stuart, and Kevin each
    • fork this repo
    • clone their respective fork (their origin)
    • add a remote pointing to upstream
  • Local commits are pushed to the respective origin remote
  • Pull requests to upstream are opened using the cloud web app
  • Conflicts are resolved locally

Demo Time!

Kevin’s conundrum

Scenario 1

Merge from upstream, push, pull request

Scenario 2

Rebase, push, pull request

Scenario 3

Let Bob sort it out…

Further Reading

Next

Upcoming topics

  • Build/release lifecycles
  • Build tools

Have Linux ready!

Questions?