Decide on basic use cases for explorer tree and scm views

We now have a couple of working prototype views available to the extension with respect to status & LFS. The questions for each of the two views are now:

1. What pain point(s) are we trying to solve?
2. Are these common enough use cases to be included in the first release?
3. What is missing from what we already have?

Here are more detailed descriptions of each of the views and my answers to the above:

A scm view (#169):

https://user-images.githubusercontent.com/37993418/114498685-e3106880-9c67-11eb-8fbf-913bb1df8385.mov

We can currently add new, push and pull modified or pull deleted.

Answers:

1. Manage files / directories that are untracked by both git and dvc or tracked by dvc.
2. Yes.
3. Enhanced support for changes made within tracked directories and ???

A custom explorer tree view (#176):

https://user-images.githubusercontent.com/37993418/115823414-a99ae280-a449-11eb-9c40-4b4ba722a3be.mov

For this view there are a couple of caveats. The current behaviour of list . does not support the main use case that we are trying to support by implementing it. Also, we could try and “stuff” this behaviour into the scm view in some form or another (but I don’t think that is a great idea).

Answers:

1. Display all files that are not on disk but exist in the remote & ???
2. If we could survive with only showing tracked directories that are missing from disk then i’d say no but I am unsure as to how often this situation comes up for users. How often do they have their workspace in a state that is mismatched with the remote / files are missing? If it is a lot then we should solve.
3. Support the basic use case if we want it for the first release.

@shcheklein @rogermparent @dberenbaum would love to get your input on this one, is there anyone else that we should rope in?

cc @yalozhkin

Thanks

[mattseddon]

Based on further discussion with @shcheklein this morning:

We want to overlay any git differences between the workspace and the previous commit onto the equivalent dvc tracked files. E.g if we have a git tracked data.dvc file and a dvc tracked data/ folder with items inside we will show the following:

data.dvc (git) status	data/ (dvc) status	visible status
M	-	M
-	M	M
M	M	M

Where - signifies unchanged from previous commit.

The next step is now to investigate dvc diff.

☝🏻 this looks pretty good. Here is some example output after dvc exp run + rm data/MNIST/raw/t10k-images-idx3-ubyte:

{
  added: [],
  deleted: [
    {
      path: 'data/MNIST/raw/t10k-images-idx3-ubyte'
    }
  ],
  modified: [
    {
      path: 'data/MNIST/raw/'
    },
    {
      path: 'logs/'
    },
    {
      path: 'logs/acc.tsv'
    },
    {
      path: 'logs/loss.tsv'
    },
    {
      path: 'model.pt'
    },
    {
      path: 'predictions.json'
    }
  ],
  renamed: [],
  'not in cache': []
}

I’ll plug diff into our file decoration and see what happens next.

We (probably) want to parse out files like 'data/MNIST/raw/t10k-images-idx3-ubyte' from the SCM view as stated previously in a follow up point (https://github.com/iterative/vscode-dvc/issues/330#issuecomment-827318034). Will keep that in mind as I spike this.

[shcheklein]

Do we want the commit action in both trees? I would have thought only in the SCM view would make the most sense?

sounds reasonable to me, our case though that we have a bit different semantics. Question though - does Git extension had actions in the projects tree? Anyways, we can start with SCM only and iterate.

Would you generally run checkout instead of pull if you believe your cache is up to date?

yes. dvc pull == dvc fetch + dvc checkout. dvc checkout all has some options like --relink to do some specific cache<–>workspace operations/adjustments.

dvc checkout runs faster since it doesn’t have to do sync cache<—>remote. Even thing like dvc status -c (dvc pull includes it naturally) can be quite expensive. dvc checkout avoids all of this. I think it will complain if some files are missing in your cache. And it’s up to you to run pull or not (maybe it’s enough to do a partial checkout).

How should we represent statuses that are listed as ‘always changed’?

let’s ignore this. This is mostly about the pipelines functionality (when .dvc contains a command to run, and some other stage that depend on it, etc). It’s not so much about data management.