Thanks for the feedback and the proposal.

Sort the view based on time

I have to say that we cannot group all requests by time as the requests are independent. We can follow this pattern in the timeline view for each resource (Settings etc., ). I liked your idea, in other issues you filed, of showing a simpler view that shows last synced data. So I can think of showing a simple view with latest data and have a filter or something to load all data.

Remove the machine item and append to the filename

👍

Update actions so that you can rollback to either a single file or to a date in time

Falls into category of grouping by time

Move context menu actions into a global ellipsis (logs, reset, etc.)

👍

• It is more helpful to know the latest state on the server (for eg., while turning on syncing). Hence added Synced Data view to show the latest state.

• Added machine name only to the first entry to avoid duplication.
• Renamed previous synced data view to be called Sync Activity (Remote) as it is indeed showing the sync activity. Made these views hidden by default as they are only used for troubleshooting.
• Also changed activity view to be sorted by time but did not group due to the reason I mentioned above

It is more helpful to know the latest state on the server (for eg., while turning on syncing)

I'm not sure I fully understand what the scenario is here. If this view is intended to be an "advanced" view for users to debug what's happening, it makes more sense to see the activity rather than the current state. I think having the additional views (Sync Activity Remote/Local) may just add confusion/noise.

I think this view should just show a list of changes where users can revert back to if needed, and that we should keep it as simple as possible (flat list).

cc @Tyriar @RMacfarlane for additional thoughts

I would be removing Synced Data view in favour of Manual Sync view that you recommended in #100346. Manual Sync view is only shown while turning on sync to help users to resolve changes manually while turning on sync.

So this will leave only following views in Sync viewlet

• Synced Machines
• Sync Activity (Remote)
• Sync Activity (Local)

I think this view should just show a list of changes where users can revert back to if needed, and that we should keep it as simple as possible (flat list).

Are you suggesting to merge the activity views?

Are you suggesting to merge the activity views?

Instead of having lots of nodes like this:

I propose we simplify the list like this:

We also need to show the Machine. How about showing machine as description and pushing the time to right aligned?

BTW Flat list requires resolving data which can cause request rate limit. Given that this view is an advanced view, I think the following is good enough.

In order to achieve flat list we need to filter these requests from rate limit @Tyriar FYI

Alternatively, we can show hierarchy only for those resources that has multiple files (as of now it is just snippets) ?

Why would rate limiting be a concern? You just need to fetch the latest for 5 or so resources, more snippets maybe but there aren't that many snippets. Rate limiting only happens when the client does 100 requests in 5 minutes

Because this is not just fetching latest versions but the view also show all versions. Hence per each resource there will be as number of requests as that of versions. So it hits the rate limit.

I have no idea what this view does now:

Both left and right clicking "settings.json (Current)" does nothing, same for Settings "(16 hrs ago)". The "undo" button looks scary and I'm too scared to click it.

When I'm in a Remote WSL workspace I see these exceptions, but it doesn't do anything in a regular Windows workspace either:

This view will be removed in favour of manual sync view. There is a bug that clicking does nothing and it is fixed in master - #101912

@sandy081 does the manual sync view allow viewing history?

There is a view already to show history which is called Sync Activity view

Currently this is hidden by default, but I changed it to be shown by default (in master).

@sandy081 oh ok, that's what I was looking for. Will check that out at some point.

As mentioned in this comment - #100347 (comment) , flat list is expensive in terms of number of server requests. Hence closing this with the current solution.