zokugun
Merge Settings from N clients
Hello there!
I was wondering what is the process for merging settings from N clients?
The most common case I'd argue it's when someone "just" starts using the extension, he has N clients to reconcile, and (like me), does not currently see the point of maintaining multiple profiles*.
I guess I could temporarily setup temporary profiles, and then do git-operations, and then re-pull from the repo?
However, honestly I'd like to avoid doing it, if you have a better idea in mind.
*Now, if we are talking that you have a base profile, and then you have a generic/specific profile, that could work ... but but then I am still wondering what do I do if I want (on the same computer) do Frontend development and D programming - on separate windows/projects. Do I keep switching profiles for each workspace? What happens if I "just want to open both projects"? 😕
*Now, if we are talking that you have a base profile, and then you have a generic/specific profile, that could work ... but but then I am still wondering what do I do if I want (on the same computer) do Frontend development and D programming - on separate windows/projects. Do I keep switching profiles for each workspace? What happens if I "just want to open both projects"? 😕
The extension syncs the settings, extensions, etc at the global level. So if you have 2 profiles, only 1 can be a applied at the same time. It seems like you would like a way to sync your workspace settings based on a template (one for Frontend and a second one for D).
The most common case I'd argue it's when someone "just" starts using the extension, he has N clients to reconcile, and (like me), does not currently see the point of maintaining multiple profiles*.
You will have the reconcile your settings into one profile.
The extension is mainly to sync between computers or different editors. But if you have any suggestion to improve your use case, they are welcome.
But if you have any suggestion to improve your use case, they are welcome.
There needs to be a "Merge" option.
I am not sure if/what is missing exactly from the current state of affairs, but how I imagine this is:
- Configure the extension to listen to a remote endpoint (I'll assume remote git for now)
- Connect to the remote endpoint, but do nothing (don't overwrite remote OR LOCAL settings)
- Select a remote profile to follow
- Extension complains "Your local profile is initialized (i.e. not empty), and different from the remote profile! What do you want to do?"
- There are the options "Use local (discard remote)", "Use remote (discard local)", "Merge profiles"
- "Merge profiles" does something, and when I validate "it's all done", then the tip of the aforementioned profile points at the resolution (either as a merge commit, or a commit on top of current
profile@HEADmentioning:Merged with codium:xyz@hostor something more informative) - Success
The "does something", can be:
- Applying the local profile on top of the remote profile as uncommitted changes, prompts you to manually commit them, push them afterwards
- Create a new root branch, commit local configuration, start a
git checkout <profile>; git merge --no-ff codium:xyz@host, prompts for you to solve the merge commit, push the changes afterwards. - .... ?
(and ofc, I haven't covered the vice versa case, or the "discard" cases)
-
It's already like that when the extension is configured.
-
- "Use local (discard remote)" = "upload"
- "Use remote (discard local)" = "download"
But not as user friendly as your description...
So basically, you want the same as https://code.visualstudio.com/docs/editor/settings-sync#_conflicts I didn't do that because I'm assuming that the dev knows what he's doing (helped with no automatic sync and possibility to preview the changes). To do the same merge as the builtin feature is going to be a lot of work (UI and how to merge the uiState database, ...)
The merge would need to support non-git repository.
So basically, you want the same as code.visualstudio.com/docs/editor/settings-sync#_conflicts ...
Exactly, but what I hear from you is that "it should be safe" to do it manually.
So, either "keep that in mind", write it down on the readme/wiki, and let's proceed like that. Or, make a feature out of it (with all the fuss that has).
... however, I also hear from you that it should be safe to onboard new clients by just creating new profiles for them, and then merging said profiles with the "main" profile. It would be nice if there was a way to "stage", but not commit, the current configuration on the selected profile. (so that I am avoiding creating new profiles, syncing dummy things, merge, push to "main" profile, change the profile to be the main profile)
The merge would need to support non-git repository.
True ... but it sounds a lot complicated to me. If you do what you said is required, then it should be easier. However, my current approach is to offload the "state" stuff to git instead - since people (should) know how to work with Git. This makes the development easier (but ofc not complete, and I get that).
In the meantime that I find a solution, you could use local git. It might help. I agree, creating a profile shouldn't make a commit. But I think I will need to add unit tests for git, it might take a while.
For all the json settings, I could:
- dump the merge into an external directory (could make it as a local git, so it would work for non-git repo)
- tell the user the user to resolve the diffs there (maybe open a new window to that directory)
- when done import the settings
- if ok, confirm the settings then the user can upload them
- if not ok, revert the settings to the previous local ones
I still wonder what to do with the uiState database (some extensions are saving settings there). I would need to look at vscode's code to see what they are doing...
PS: And I was thinking to add support to theia-based editors and online editors...