reducing confusion between dvc remote and git remote

[skshetry]

I have seen too many people getting confused over dvc vs git remote.

Looks like this should be handled by dvc after all.

We could either:

1. Change terminology from remote to storage or cache, similarly change commands:

dvc storage add s3 s3://bucket/

We can keep using remote as an alias.

2. Try to see if the remote url is a git remote based on heuristics (eg: if domain name is github for example) and thrown a error and a hint for what to do.

... More ideas?

cc @jorgeorpinel

[shcheklein]

It's a good one. The only thing to keep in mind that we use our "remotes" not only as storages - e.g. remote:// notation for external deps/outs.

[skshetry]

storage:// make more sense to me as well. Again, we can keep remote:// as an alias if we don't want to break compatibility.

$ dvc add storage://dvc-test/123

[efiop]

How would the other commands look like? E.g. push/pull?

dvc push --storage mys3

?

Should we change the terminology for the .dvc/cache too?

[jorgeorpinel]

Change terminology from remote to storage... keep using remote as an alias

➕1️⃣ !!! I would maybe just use the term "cache storage" sometimes in key places of the docs.

dvc push --storage mys3

@efiop -s/--storage should work, yes.

change the terminology for the .dvc/cache too?

What do you mean? As in .dvc/storage? I think that's a separate question, could be considered but term "cache" isn't a source of confusion AFAI. Again, I think we can associate the concepts effectively in key docs.

[efiop]

$ dvc add storage://dvc-test/123

@skshetry Btw, this doesn't look very good. See #3920 , it feels like this use case is a "workspace" case. And this might be where storage might be confusing, as it is too ambiguous, whereas remote is a storage in dvc-specific format (our cache format), which is similar to git remotes.

[efiop]

What do you mean? As in .dvc/storage? I think that's a separate question, could be considered but term "cache" isn't a source of confusion AFAI. Again, I think we can associate the concepts effectively in key docs.

@jorgeorpinel We have actually heard questions about it too 🙂 It is really closer to .git/objects.