Sync separately for each flavour of VS Code

[sandy081]

Syncing user data should not overlap for eg, insiders should not sync with stable they should be syncing separately.

[sanket-bhalerao]

can we have the option to keep insiders and stable with the same settings?
i use insiders as my primary editor and stable as a fallback in case insiders is having some major issue. so stable being my fallback option i would like it to behave pretty much as the insiders (settings, keyboard shortcuts, extensions, etc wise)
if there are experimental features which can only be activated in insiders, then that's fine

[sandy081]

From @JacksonKearl: Can this be made an option? I would like Insiders and Stable to be consistent.

Re: @sandy081: Insiders and Stable are different products and allowing to use same endpoint to sync is not a good idea. I think this is not a very common use case and we can allow users to customise the endpoint to fulfil this.

Re @JacksonKearl: I think people switch between Insiders and Stable when a) theres a feature/bug fix they want to use in Insiders that isn't out in Stable yet, or b) there's a bug in Insiders and they need to go back to Stable to do their work. In neither of those cases are they trying to "switch profiles" and I think not having your profile synced would be unexpected.

[carlocardella]

I agree with @sanket-bhalerao and, it seems @JacksonKearl : Insiders is my primary editor and I use stable as fallback (sometimes I don't open if for weeks), but I keep both versions in sync against the same Gist. If Insiders has a bug or something, I fire up Stable, sync my settings and I'm good to go with all my extensions, keyboard shortcuts, theme etc...

[sandy081]

It makes sense that sync data should always be associated to the account that user has logged in and should not distinguish by the product user is using. It is suggested to create two separate accounts to separate syncing insiders and stable.

@microsoft/vscode Opinions?

[jrieken]

Yeah - separate. Otherwise you might sync a setting to stable that only makes sense in insiders and that then gets "cleaned up".

[carlocardella]

Yeah - separate. Otherwise you might sync a setting to stable that only makes sense in insiders and that then gets "cleaned up".

I don't have this problem now: if Insiders introduces a setting that Stable does not recognize, the setting is simply ignored (shown with a dimmed color in the json setting editor)

[Tyriar]

Yeah - separate. Otherwise you might sync a setting to stable that only makes sense in insiders and that then gets "cleaned up".

This will almost always never matter as @carlocardella's calls out. It's similar to my issue where I want keybindings to be shared across all platforms (which is a setting), not having this will just result in a bunch of manual sync work for me which will inevitably get out of sync across windows/mac/linux.

If people feel strongly about this I think we should have a setting that tells whether to share between stable and insiders that is on by default.

[miguelsolorio]

+1 for sync being the same across all versions, especially when you consider our Exploration builds. I would say that this would help increase the usage of those builds (Insiders and Exploration) since it would be easier to pickup.

I also think the primary use case for this, as mentioned already, is moving to Stable when Insiders is broken.

[carlocardella]

If people feel strongly about this I think we should have a setting that tells whether to share between stable and insiders that is on by default.

Good idea, I like it

[sbatten]

+1 for syncing across, its the primary reason I used the OG setting sync extension to begin with, not for multiple machines but multiple versions. And I don't believe having multiple accounts for anything should be suggested practice. Simply having some kind of flag should be sufficient.

[Tyriar]

If people feel strongly about this I think we should have a setting that tells whether to share between stable and insiders that is on by default.

To add to this, it's preferable for it not to be supported at all as otherwise work needs to happen on the server to enable this. So I really mean only if people feel strongly that this will be generally useful (and not just to the VS Code team for testing).

[jrieken]

I agree that being able to use different flavours of vscode side by side without friction has a big plus but I am a little scared of implications that we don't know yet. E.g when sync'ing UI state (which is internal) does it mean we need to keep the format N-1 compatible so that data from insiders (N) can be understood by stable (N-1)?

[Tyriar]

@jrieken it's unclear what "UI state" will include in the future, right now it's just the display language which you would want synced regardless of quality. @sandy081?

[jrieken]

Yeah, while it's unclear what else we onboard onto settings sync making it work across flavours will impose some kind of compatibility constraint. Or we close the list of items to sync today (which I believe is unlikely given that we cannot predict the future)

[Tyriar]

@jrieken another idea I had while talking to @sandy081 about this was to sync everything across both except for UI state which is always quality-specific. It's hard to make a call on something like that without knowing what it will contain. If doing this makes sense maybe display language should be pulled out, it's configured differently to "UI state" anyway in locale.json.

[sandy081]

UI State is open ended and I do not have the list. It can include workbench layout like view and view containers visibility and position. I think we shall have to address the issue of UI state compatibility anyway (irrespective of supporting syncing across products) because as user can have two machines with insiders or stable on different versions.

[sandy081]

If we have to handle syncing UI state based on its compatibility then we should use the same across qualities (if we want to sync across) and do not make quality specific.

[sandy081]

We concluded to support syncing across products (insiders, stable, web...). Recommendation for separating is to use separate accounts.