DVC (Data Version Control) extends Git to handle large files and machine learning pipelines, providing version control for datasets and models, and enabling reproducible ML workflows. It stores data and model files in a cache outside of Git, supporting various remote storage platforms (S3, Azure, Google Cloud, SSH, etc.). The current version is 3.67.1, with frequent releases.
pip install dvcVerified import paths — ran on the pinned version, not inferred.
This quickstart first sets up a minimal DVC project using shell commands (simulated via `subprocess`) to initialize DVC within a Git repository and track a `data.csv` file. It then demonstrates how to use the `dvc.api.read()` function in Python to programmatically access the content of the DVC-tracked file.
To restore the previous recursive behavior when checking a directory with `dvc status --cloud`, add the `--recursive` option.
After migrating your local repository to 3.x (e.g., using `dvc cache migrate --dvc-files`), you may need to re-upload all 3.x data to your remote storage for consistency. Consider the impact on remote storage and network usage.
Use `dvc add` for initial data versioning and `dvc commit` only when data or pipelines are in a stable, significant state. For intermediate or pipeline-generated outputs, rely on DVC's pipeline system (`dvc.yaml`) which handles caching automatically. Use the `--no-commit` option with `dvc add` or `dvc run` if you want to track data without immediately caching it.
If encountering `pathspec` dependency conflicts around DVC 3.66.0, upgrade to DVC 3.67.0 or later, which includes `pathspec v1` support, or adjust your environment to ensure compatible `pathspec` versions for all tools.
Install DVC using `pip install dvc` (or `conda install -c conda-forge dvc`) and then restart your terminal or re-source your shell configuration file (e.g., `.bashrc`, `.zshrc`) to update the PATH.
Ensure the data was `dvc push`ed from the source repository. If the data exists in the remote, try `dvc pull` again. If the local cache is suspected to be corrupted, use `dvc cache dir --local` to locate the cache and manually clean problematic entries if necessary, or consider `dvc destroy -f` if you are confident in remote data integrity and need to reset the cache.
Navigate to the root directory of your DVC project (where the `.dvc` folder is located) or initialize a DVC repository using `dvc init` if you intend to start a new DVC project in the current directory.
Verify your remote configuration (`dvc remote list -v`, `dvc remote modify`) and ensure correct authentication credentials. Check network connectivity to the remote and try running `dvc push -v` for more verbose output to pinpoint the exact failure reason. For S3 remotes, consider installing `dvc-s3` for automatic retries.
Double-check that all file paths referenced in your `dvc.yaml` stages or DVC commands exist and are accessible. If pulling data, ensure the remote contains the expected files. If `cache.type` is set to `symlink`, try switching to `copy` or `hardlink` if the cache directory is on a different drive than the workspace, or if the filesystem doesn't fully support symlinks.