Test: SCM - maintain working sets when switching branches

[lszomoru]

Refs: #35307

• anyOS @bpasero
• anyOS @karthiknadig
• anyOS @andreamah

Complexity: 5

Create Issue

---

This milestone we have implemented the first iteration of associating a working set (editors, editor layout) with a source control branch. When the feature is enabled, switching between source control branches will save/restore the working set.

🎯 What editors are included in the working set? As we do not want to interrupt switching branches with various modal dialogs, at the moment only editors the case be safely closed are included in the working set. The following editors are not included in the working set: untitled files, dirty files, custom editors that cannot be safely closed.

🎯 Working sets are being saved/restored after the branch switching completes. There are various scenarios in which git is unable to switch branches and working sets does not try to improve on that. In the case in which git is unable to switch the current branch the working set will not be saved/restored.

Prerequisites

• Install the latest version of VS Code Insiders
• Configure the user settings as follows:
  • files.autoSave set to off
  • scm.workingSets.enabled set to true
  • scm.workingSets.default set to current

Single-repository folder/workspace

• Launch VS Code Insider
• Open a folder/workspace that contains a git repository
• Switch to the git repository's default branch (ex: main)
• Open a bunch of files and place them in the workbench grid
• Modify some of the file (but do not save the changes)
• Add some untitled files
• Click on the branch indicator in the status bar and create a new branch
  • Confirm that the current working set is used for the new branch
• On the new branch close some of the editors, and open others
• Use the branch indicator in the status bar and switch back to main
  • Confirm that the working set associated with the main branch is restored
  • Confirm that the dirty editors and untitled files remain opened
• Use the branch indicator in the status bar and switch back to previous topic branch
  • Confirm that the working set associated with the topic branch is restored
  • Confirm that the dirty editors and untitled files remain opened

Single-repository folder/workspace (empty working set)

• Launch VS Code Insider
• Open a folder/workspace that contains a git repository
• Switch to the git repository's default branch (ex: main)
• Open you user settings and set scm.workingSets.default to empty
• Open a bunch of files and place them in the workbench grid
• Modify some of the file (but do not save the changes)
• Add some untitled files
• Click on the branch indicator in the status bar and create a new branch
  • Confirm that all untitled and dirty editors remain opened
  • Confirm that all saved files get closed
• Click on the branch indicator in the status bar and switch back to the main branch
  • Confirm that all untitled and dirty editors remain opened
  • Confirm that the working set associated with main branch is restored

Multi-repository folder/workspace

• Launch VS Code Insider
• Open a folder/workspace that contains multiple git repositories
• Open the "Source Control Repositories" view and select all repositories
• Open files from multiple repositories
• Use the branch indicator in the status bar to switch the branch of the active repository. At the moment we always associate the complete working set (all files from all repositories) to the repository/branch that was changed. Does this feel natural or does that cause confusion?
• Try out various scenarios in the multi-repository workspace and see if there would be any behaviour that you would like to control (probably through settings)

[andreamah]

Everything works as expected. I think that the multi-repo state is quite interesting, I found it a little confusing to predict what it will do when I had ~6 repos open, but I expect that people will have less than that open and that they'll likely be only using this setting if they're actually really context-switching when switching branches. In that sense, the flow makes sense to me.

[karthiknadig]

May be it can have the folder name along with the branch name. It was hard to know which main it was without hovering:

Although, I don't commonly use this feature so I am not sure if this is ok with regular users.

[thernstig]

@lszomoru if using VS Code Profiles, it seems this setting does not work when set in the application settings. Is this intentional?

[lszomoru]

@thernstig, this is expected behaviour. You will have to "promote" the setting so that its value if applied to app profiles - https://code.visualstudio.com/docs/editor/profiles#_applying-a-setting-to-all-profiles.

[thernstig]

@lszomoru not the first time I forget about that. Probably worth to write an issue on that text if I get a chance, considering it can be improved mentioning this.