Logo
← Back to Blog

Development and optimization

DVC Notes

A practical workflow for using DVC to track datasets and checkpoints, store large data outside Git, push updates to a DVC remote, and restore the same data on another machine.

The workflow in these notes keeps large datasets and checkpoints under DVC while Git stores the DVC metadata and the rest of the project code.

Install DVC

Terminal
uv tool install dvc

Initialize DVC

Run DVC initialization from the main project folder.

Terminal
dvc init

This creates DVC configuration files such as:

Project structure
.dvc/
.dvcignore

Check and commit the setup with Git

Terminal
git status

git add .dvc .dvcignore
git commit -m "Initialize DVC"

Create the DVC control structure

The source note uses a dedicated dvcControl folder to separate datasets and model checkpoints from the rest of the project.

Terminal
mkdir -p dvcControl/dataset
mkdir -p dvcControl/ckpt
Example structure
dvcControl/
├── dataset/
│   ├── my_dataset1/
│   └── my_dataset2/
└── ckpt/
    └── yolo11m_exp1/
Directory naming in the source note

The original note uses both dataset and datasets in different commands. Choose one directory name and keep it consistent in your project.

Configure a DVC remote

The remote is the directory used to store the actual DVC managed data.

01

Local remote

Machine specific storage kept in local DVC configuration.

02

Default remote

A remote marked with -d becomes the default remote.

03

Named remote

Use -r when pushing to a specific remote instead of the default one.

Local remote for one machine

Terminal
dvc remote add -d <remoteName> <directory> --local

# Examples from the note
dvc remote add -d thermal_object_detection //mnt/d/DATA_CKPT/thermal_project --local
dvc remote add -d thermal_object_detection /home/ducan/DiskD/DATA_CKPT/thermal_project --local
Why use --local?

In the source workflow, machine specific remote paths are kept in the local DVC configuration instead of the shared project configuration.

Shared project remote

Terminal
dvc remote add -d <remoteName> <location>

# Example
dvc remote add -d thermal_data //mnt/d/DATA_CKPT/thermal_project

Different remote names for different systems

Terminal
# WSL
dvc remote add wsl_d //mnt/d/DATA_CKPT/thermal_project
dvc push -r wsl_d

# Ubuntu
dvc remote add ubuntu_d /media/ducan/Data/dvc_storage/yolo11
dvc push -r ubuntu_d

List or remove remotes

Terminal
dvc remote list

dvc remote remove <remoteName>

# Example
dvc remote remove thermal_data

Track datasets and checkpoints

The source note tracks the checkpoint and dataset folders with DVC while keeping the actual large files out of Git.

Git ignore

The note recommends adding checkpoint and dataset directories to .gitignore so Git does not track the large data directly.

Terminal
dvc add dvcControl/ckpt
dvc add dvcControl/dataset

Update and push new data

When tracked data changes, update the DVC metadata, commit that metadata with Git, then push both DVC data and Git history.

Terminal
# Check DVC status
dvc status

# Update DVC tracking after data changes
dvc add <fileControl>

# Examples from the note
dvc add dvcControl/ckpt
dvc add dvcControl/dataset

# Add the updated DVC metadata to Git
git add <dvcFile.dvc>

# Commit DVC metadata
git commit -m "Update DVC data"

# Push DVC data and Git history
dvc push
git push

Pull data on another machine

Terminal
dvc pull

Remote and versioning notes

Check configured DVC remotes

Terminal
dvc remote list

Use Git tags for dataset versions

The source note recommends tagging dataset updates so a specific dataset version can be referenced later.

Example from the note
dvc import https://github.com/duc-an-nguyen/yolo11.git dvcControl/dataset --rev dataset-v2

Set up DVC on a new device or OS

Clone the Git repository, configure the machine specific DVC storage path, then pull the tracked data.

Terminal
git clone <your_repo>
cd <your_repo>

dvc remote add -d d_drive <local-path-to-dvc-storage> --local

dvc pull