Allow me to continue in an existing location?

[bpasero]

Testing #161875

When I want to continue in a Codespace, currently I always have to create a new Codespace, but couldn't we allow to continue in a previous location I had created?

[joyceerhl]

I think the reason we don't already have this is that

1. from a feature standpoint, my understanding is that codespaces are meant to be created 'disposably', i.e. you spin them up and delete them as necessary, so the recommendation instead would be to always create a new codespace
2. from a technical standpoint, it would be additional work to get the private git state in the codespace in sync. For example if I want to continue in an existing codespace which has a different branch checked out, or the same branch with unpublished local commits, we now risk the transferred edit state no longer being valid

[bpasero]

I think this ends up being the decision of the provider of the "target" of where to continue in. So if Codespaces could support this eventually, then maybe this needs to be something the extension can signal from the picker.

What I am not yet fully understanding: once I picked a target to "continue in", my understanding is that target is under an active edit session, i.e. changes are synced from now on in both directions (in and out). So now, when I am back in my local workspace and go through the "Continue in..." flow again, wouldn't it then make sense to offer me that target that already has this edit session enabled?

[joyceerhl]

if Codespaces could support this eventually, then maybe this needs to be something the extension can signal from the picker

Yeah I think this would be the Codespaces extension contributing another option to Continue in Existing Codespace, in addition to the option to Create New Codespace.

changes are synced from now on in both directions

At the moment, edit sessions are a one-way transfer that takes place the moment you pick a Continue On option. The bidirectional sync is attractive but gets quickly complicated if you have multiple clients with diverging changes--ideally I think we would want to be able to resolve them without requiring manual user intervention, which ultimately calls for some kind of OT/CRDT-based merging and becomes more of a roadmap item.

To alleviate this limitation for now, there is an experimental autoStore setting which will upload your edit session on shutdown, which means that when you next open a workspace that the edit session is relevant to, that edit session should automatically restore. However, I've kept that experimental because there are issues to work through regarding not storing the edit session if it's just a window reload, as well as problems with it being long-running in web. The edit session will currently also become 'orphaned' if the edit session identifier changes (e.g. the branch is fast forwarded), and there is work for me to surface such edit sessions so that users don't lose them.

[joyceerhl]

Related: https://github.com/microsoft/vscode/issues/162031

[bpasero]

Oh I see, I was not aware of this limitation. I agree, if we only sync the edit session changes up at the moment when I click the "Continue on...." command then it makes sense that the target I continue in is always fresh.

But that said, what if I pick a target that actually does exist already? I can see how a Codespace is always new, but what about insiders.vscode.dev which is somewhat the same always? Or even on desktop via remote repositories extension?

[bpasero]

Btw if this is true:

At the moment, edit sessions are a one-way transfer that takes place the moment you pick a Continue On option.

Then I do not really understand why we surface "Edit Sessions" in the account menu. That is related to my confusion in https://github.com/microsoft/vscode/issues/162117

[joyceerhl]

what about insiders.vscode.dev which is somewhat the same always? Or even on desktop via remote repositories extension?

Yeah in these scenarios you would get a modal dialog asking whether you want to overwrite your changes, so continuing in a codespace or a new clone is preferable.

At the moment, edit sessions are a one-way transfer that takes place the moment you pick a Continue On option.

should be amended to say

At the moment, edit sessions are a one-way transfer that takes place the moment you pick a Continue On option provided that you turned on edit sessions during the current or a prior Continue On flow.