Misc updates (1.0)

content/docs/command-reference/repro.md

@@ -42,10 +42,9 @@ and <abbr>caches</abbr> the pipeline's <abbr>outputs</abbr> along the way.
 💡 For convenience, a Git hook is available to remind you to `dvc repro` when
 needed after a `git commit`. See `dvc install` for more details.
 
-[Stage](/doc/command-reference/run) outputs are deleted from the
-<abbr>workspace</abbr> before executing the stage commands that produce them.
-`dvc repro` does not run `dvc fetch`, `dvc pull` or `dvc checkout` to get data
-files, intermediate or final results (except if the `--pull` option is used).
+By default, this command checks all [pipeline](/doc/command-reference/dag)
+stages to determine which ones have changed. Then it executes the corresponding
+commands (`cmd` field of `dvc.yaml`).
 
 There are a few ways to restrict what will be regenerated by this command: by
 specifying specific reproduction [`targets`](#options), or by using certain
@@ -54,6 +53,13 @@ command [options](#options), such as `--single-item` or `--all-pipelines`.
 > Note that stages without dependencies are considered _always changed_, so
 > `dvc repro` always executes them.
 
+[Stage](/doc/command-reference/run) outputs are deleted from the
+<abbr>workspace</abbr> before executing the stage commands that produce them
+(unless `persist: true` is used in `dvc.yaml`).
+
+`dvc repro` does not run `dvc fetch`, `dvc pull` or `dvc checkout` to get data
+files, intermediate or final results (except if the `--pull` option is used).
+
 It stores all the data files, intermediate or final results in the
 <abbr>cache</abbr> (unless the `--no-commit` option is used), and updates the
 hash values of changed dependencies and outputs in the `dvc.lock` and `.dvc`

content/docs/start/index.md

@@ -48,13 +48,15 @@ Changes to be committed:
 $ git commit -m "Initialize DVC"
 ```
 
-DVC features can be grouped into functional components. We'll explore them one
-by one in the next few sections:
+Now you're ready to DVC!
 
-- [**Data versioning**](/doc/start/data-versioning) is the base layer of DVC for
-  large files, datasets, and machine learning models. It looks like a regular
-  Git workflow, but without storing large files in the repo (think "Git for
-  data"). Data is stored separately, which allows for efficient sharing.
+DVC's features can be grouped into functional components. We'll explore them one
+by one in the next few pages:
+
+- [**Data versioning**](/doc/start/data-versioning) (try this next) is the base
+  layer of DVC for large files, datasets, and machine learning models. Use a
+  regular Git workflow, but without storing large files in the repo (think "Git
+  for data"). Data is stored separately, which allows for efficient sharing.
 
 - [**Data access**](/doc/start/data-access) shows how to use data artifacts from
   outside of the project and how to import data artifacts from another DVC

content/docs/use-cases/data-registries.md

@@ -30,7 +30,7 @@ Advantages of data registries:
   management and optimizes space requirements.
 - **Data as code**: leverage Git workflows such as commits, branching, pull
   requests, reviews, and even CI/CD for your data and models lifecycle. Think
-  "Git for cloud storage", but without ad-hoc conventions.
+  "Git for cloud storage".
 - **Security**: registries can be setup with read-only remote storage (e.g. an
   HTTP server).
 

content/docs/user-guide/dvc-files.md

@@ -79,7 +79,8 @@ and `dvc commit` commands, but not when a `.dvc` file is overwritten by
   HTTP, S3, or Azure [external outputs](/doc/user-guide/managing-external-data);
   and a special _checksum_ for HDFS and WebHDFS.
 - `size`: Size of the file or directory (sum of all files).
-- `nfiles`: If a directory, number of files inside.
+- `nfiles`: If this output is a directory, the number of files inside
+  (recursive).
 - `isexec`: Whether this is an executable file. DVC preserves execute
   permissions upon `dvc checkout` and `dvc pull`. This has no effect on
   directories, or in general on Windows.
@@ -88,8 +89,8 @@ and `dvc commit` commands, but not when a `.dvc` file is overwritten by
 - `persist`: Whether the output file/dir should remain in place while
   `dvc repro` runs. By default outputs are deleted when `dvc repro` starts (if
   this value is not present).
-- `desc`: User description for this output. This doesn't affect any DVC
-  operations.
+- `desc` (optional): User description for this output. This doesn't affect any
+  DVC operations.
 
 ### Dependency entries
 
@@ -103,7 +104,8 @@ and `dvc commit` commands, but not when a `.dvc` file is overwritten by
   HTTP, S3, or Azure <abbr>external dependencies</abbr>; and a special
   _checksum_ for HDFS and WebHDFS. See `dvc import-url` for more information.
 - `size`: Size of the file or directory (sum of all files).
-- `nfiles`: If a directory, number of files inside.
+- `nfiles`: If this dependency is a directory, the number of files inside
+  (recursive).
 - `repo`: This entry is only for external dependencies created with
   `dvc import`, and can contains the following fields:
 
@@ -142,9 +144,7 @@ stages:
       - performance.json
   training:
     desc: Training stage description
-    cmd:
-      - pip install -r requirements.txt
-      - python train.py
+    cmd: python train.py
     deps:
       - train.py
       - features
@@ -163,10 +163,7 @@ stages:
 by the user with the `--name` (`-n`) option of `dvc run`. Each stage can contain
 the following fields:
 
-- `cmd` (always present): One or more commands executed by the stage (may
-  contain either a single value, or a list). Commands are executed sequentially
-  until all are finished or until one of them fails (see
-  [`dvc repro`](/doc/command-reference/repro) for details).
+- `cmd` (always present): Executable command defined in this stage
 - `wdir`: Working directory for the stage command to run in (relative to the
   file's location). If this field is not present explicitly, it defaults to `.`
   (the file's location).

content/docs/user-guide/how-to/merge-conflicts.md

@@ -36,9 +36,8 @@ stages:
 
 ## `dvc.lock`
 
-There's no need to resolve lock file conflicts manually. You can safely delete
-this file and then use `dvc repro` after merging `dvc.yaml` to regenerate this
-file.
+There's no need to resolve lock file conflicts manually. You can safely
+overwrite this file by using `dvc repro` after merging `dvc.yaml`.
 
 > `dvc commit` can also be a good option, but only for the specific case where
 > the `HEAD` version is chosen.

content/docs/user-guide/setup-google-drive-remote.md

@@ -215,7 +215,7 @@ individually.
 
 If you use multiple GDrive remotes, by default they will be sharing the same
 `.dvc/tmp/gdrive-user-credentials.json` file. It can be overridden with the
-`gdrive_user_credentials_file` setting:
+`gdrive_user_credentials_file` parameter:
 
 ```dvc
 $ dvc remote modify myremote gdrive_user_credentials_file \