Steps to Reproduce:
Does this issue occur when all extensions are disabled?: Yes (with all other extensions apart from the svn one)
Works in VSCode v1.47.3
Confirming the same behavior, diff gutters are gone.
VS Code: Version: 1.48.0
OS: Mac OS 10.12.4
Confirming the same behavior in vscode-hg: https://github.com/mrcrowl/vscode-hg/issues/158
Looking at git extension, seems it is using registerFileSystemProvider, while vscode-hg uses registerTextDocumentContentProvider. I'm not sure what the differences are between the two.
I've reimplemented Mercurial's context provider in terms of registerFileSystemProvider and the gutter indicator works.
Used https://github.com/microsoft/vscode/blob/master/extensions/git/src/fileSystemProvider.ts as reference.
@joaomoreno @mjbvz please let us know if SCM extensions should be moved to use FileSystemProvider or stick to TextDocumentContentProvider
FileSystemProvider was added to git on 7 Nov 2019 (https://github.com/microsoft/vscode/commit/5d60b7fdc4d1e22a951083ad1870153431265334)
TextDocumentContentProvider was removed from git on 15 Apr 2020 (https://github.com/microsoft/vscode/commit/b8512b2055f4cfa63971bd83f49ea4c835e9cfcc)
since @joaomoreno is on vacation forwarding to @eamodio as he might know more
@hdpoliveira As for a recommendation, I would say it depends on the use-case. If you were to start today, I would definitely recommend using a FileSystemProvider (even though its harder to use, it provides the ability to do a lot more and better deals with any encoding issues (since it uses the built-in vscode encoding mechanisms). At the same time, if you have a narrower use-case and TextDocumentContentProvider is fulfilling your needs, I don't see a reason to switch. And we aren't planning to deprecate the TextDocumentContentProvider or anything.
I will dig into what changed with the TextDocumentContentProvider that's causing this issue.
Hi @eamodio !
I decided to switch to FileSystemProvider in Mercurial extesion, given that Git extension is using it and Perforce extension is too.
I'm pretty sure this was introduced because of this commit: https://github.com/microsoft/vscode/commit/003a3678c879ee5e9a72ad9e5088d89672d75bd8, but still investigating a fix
@eamodio thanks for investigating, should this be a candidate (sounds like a regression, but not high impact). You would know better.
I can also confirm with @JohnstonCode, except my OS is Windows 10. I'm using SVN as the SCM.
The issue has gone away - I can see the gutters are now available again with release 1.48.2.
The issue has gone away - I can see the gutters are now available again with release 1.48.2.
The issue is still there for me - Ubuntu 18.04, vscode 1.48.2.
Can confirm gutter diff is showing up again on 1.48.2 under Windows and Linux.
Okay, gutter diff is showing up again, but only if you get the latest version of SVN-SCM (https://github.com/JohnstonCode/svn-scm/pull/1053), the fix was not due to the new VSCode release (1.48.2).
@joaomoreno @mjbvz please let us know if SCM extensions should be moved to use FileSystemProvider or stick to TextDocumentContentProvider
This was definitely an unintended breakage. Looking into where the assumption actually breaks down...
I believe the wrong assumption lies here: https://github.com/microsoft/vscode/blob/018e9a21f1c50e8b09ff72e523bb431da36dc309/src/vs/workbench/contrib/scm/browser/dirtydiffDecorator.ts#L1145-L1145
This breaks down with model references coming in from TextDocumentContentProvider, in ref.object is an instance of ResourceEditorModel which does not implement IResolvedTextFileEditorModel. @bpasero I remember we did this together, can you guide towards a solution here?
Thanks to @bpasero for the help in fixing this!
Confirmed that this works now works using an svn project:

When will this fix be released? v1.49?
@DavidGoldman yes, this will be in out in the August release (1.49) which should drop next week. It's already fixed on our Insiders (nightly build). You can also use Settings Sync to sync your settings/extensions/keybindings between Insiders and Stable.
Most helpful comment
Thanks to @bpasero for the help in fixing this!