从 DVC 2.x 升级到 DVC 3.0
DVC 3.0 引入了文件哈希计算方式以及 DVC 跟踪数据在缓存中存储位置的变更。DVC 3.0 仍兼容 DVC 2.0 之前已跟踪的数据，但在升级到 DVC 3.0 时，用户需要注意一些重要事项。
有关 DVC 3.0 中所有不兼容变更的完整列表，请参阅发布说明。
文件哈希变更
此前，DVC 会尝试判断一个被跟踪的文件是否包含文本内容，并在哈希计算前将 Windows 风格的 CRLF 换行符转换为 Unix 风格的 LF 换行符（即执行dos2unix 转换）。此行为旨在简化跨平台场景下的使用（即在 Unix 和 Windows 机器上共用同一个DVC 仓库）。然而，尽管 DVC 在计算哈希时会转换换行符，但原始本地内容仍会被保留在本地 DVC 缓存和远程存储中。这会导致一些意外情况，例如当某个二进制文件被 DVC 错误识别为文本文件，或某个文本文件本就不打算跨平台使用（此时 CRLF 不应被视为与 LF 等效）。
在 DVC 3.0 中，已移除换行符转换行为，DVC 将所有文件视为二进制数据处理。这意味着，即使两个文件的其余文本内容完全相同，只要一个使用 CRLF 换行而另一个使用 LF 换行，它们就会被视为完全不同的文件。
升级到 DVC 3.0 后，若用户的流水线可能在 Unix 和 Windows 环境中运行，则应确保所有生成文本输出的流水线阶段（如 .csv 或 .tsv 文件）无论在何种平台上运行，都生成一致的换行符格式。
例如，Python 阶段应显式生成使用 Unix 风格 \n 或 Windows 风格 \r\n 换行符的文件，而不应依赖默认的平台相关 os.linesep 行为。
可选的本地缓存迁移
为了避免 DVC 3.0 与旧版本之间出现哈希冲突，DVC 3.0 跟踪的文件将与旧版本跟踪的文件分开存储。默认情况下，DVC 不会在 DVC 3.0 与旧版本所跟踪的文件之间自动去重。DVC 仍可读取 DVC 2.0 的缓存文件，仅对新数据或修改过的数据进行重复存储。
用户可通过运行 dvc cache migrate 命令手动将现有本地 DVC 缓存数据迁移到 DVC 3.0 的位置。在大多数本地文件系统上，dvc cache migrate 相当于强制对 DVC 3.0 与旧版本所跟踪的文件进行去重。旧缓存位置中的文件将使用 DVC 3.0 的哈希算法重新计算哈希值，原子性地移动到新的缓存位置，并在原位置创建指向新位置的链接。此过程可能耗时较长。
对于不支持任何类型链接的文件系统，数据将从旧缓存位置复制到 DVC 3.0 位置（因此不会实现去重）。
默认情况下，dvc cache migrate 仅迁移缓存数据，不会修改 DVC 仓库 中的 DVC 文件。dvc cache migrate --dvc-files 将会迁移仓库中所有 DVC 文件中的条目，从而使 DVC 仅使用 DVC 3.0 缓存位置的数据。
请注意，使用 --dvc-files 选项时，DVC 仅会迁移 工作区 中的 DVC 文件（不会重写 Git 历史记录）。
对于DVC 远程存储，由于在许多远程文件系统上无法在新旧位置之间建立链接，因此没有对应的迁移命令。相反，在本地完成数据迁移并推送到远程后，可以使用 dvc gc -c 命令从远程删除过时的数据。