---
format:
    revealjs:
        theme: simple
        chalkboard: true
        auto-stretch: false
---

## Versioning

Keith VanderLinden<br>
Calvin University

## Project Management

We&rsquo;ll be adapting the use of project management tools developed for software engineering.

- *Artifacts*: Git/GitHub
- *Tasks*: GitHub Projects
- *Time*: Clockify

::: {.notes}
- Overview: CS and DS projects are:
    - *Different* in that they focus on different things and manage different artifacts (q.v. module 1).
    - *Similar* in that they both must do project management (q.v. modules 2--3).
- We will re-purpose SE project management tools for use in ML/Data Engineering.
    - DS artifacts are still drafted, edited, maintained over time, delivered.
    - DS projects must still manage multiple, self-interacting tasks done by multiple, collaborating people over time.
- Schedule:
    - DVCS - this week - managing artifacts over time
    - Task/Time management - next week - managing people over time
:::

## Version Control Systems

- Version control systems (VCSs) are used by *teams* to manage *artifacts* over *time*.
    - *Centralized* VCSs maintain a single, central repository of shared artifacts.
    - *Distributed* VCSs maintain a copy of the repository on each client machine.

::: {.notes}
- Version control systems (VCSs) are used by *teams* to manage *artifacts* over *time*.
    - *Teams* - multiple people working together on a project.
    - *Artifacts* - code; datasets; notebooks; documentation; images; presentations; etc.
    - *Time* - a version history of artifacts is maintained over time
- DVCSs are (most?) common, but some companies are using CVCSs, e.g.:
    - Azure DevOps Server (<https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/what-is-tfvc?view=azure-devops>)
    - AccuRev (<https://en.wikipedia.org/wiki/AccuRev_SCM>)
:::

## Distributed Version Control Systems

*See the live walkthrough.*

![](images/git-walkthrough.png)

::: {.notes}
- Conceptual Walkthrough - Follow this [CS 262 deployment diagram example](https://github.com/kvlinden-courses/cs262/blob/master/materials/03management/dvcs.png).
    1. Start with empty client GitHub *repo* (short for *repository*).
    2. "Copy" the repo down to a local machine to two local machines (A & B).
        - Distinguish different ways to "copy" the repo:
            - *fork* - new, independent application
            - *clone* - shared project - We'll use clone.
        - Distinguish between Git and GitHub.
            - Git is the DVCS software.
            - GitHub is a cloud-based service that hosts Git repos.
        - Either way, the full copy is what makes it *distributed*.
            - Everyone has a full copy of the repo, including the full revision history.
            - Cf. maintaining/sharing a single, cloud-based copy shared by all.
    3. Client A `add` some code, `commit` it locally, and `push` the changes to GitHub.
        - New/modified files start as *un-staged*. `add` stages them for commit.
        - Distinguish different ways to "save" changes:
            - *commit* - save changes locally
            - *push* - save changes to GitHub
        - Note that not all files are staged/committed/pushed.
            - Some files are *ignored* (e.g., compiled code, temporary files, etc.).
    4. Client B `add`/`commit` changes locally but must `pull` changes before pushing,
        perhaps `merge` them with local changes.

References

- DVCS materials on Wednesday: <https://github.com/kvlinden-courses/cs262/blob/master/materials/03management/class.md>
- Git/GitHub deployment diagram: <https://cs.calvin.edu/courses/cs/262/kvlinden/03management/images/dvcs.png>
- Git commit/push/out (on quiz): <https://i.ebayimg.com/images/g/GQQAAOSwYsBbxwgu/s-l640.jpg>
:::
