Consider IT support needs

[hahn-kev]

With Chorus IT support has a number of tools, most of them are specifically for hg, but there's some like the LCM model viewer that maybe relevant here too.

The good news is that since the data is stored in sqlite any tool for looking at a sqlite database would work great. Some things that might be useful which may not be simple with just a simple database tool:

• list changes made after an object was deleted
• find hybrid clock time issues (lots of commits with the same time and different counters)
• get snapshot at a point in time
• replay changes / make object from scratch and compare with current snapshot

[myieye]

My previous company had a developer page that was loaded with hundreds of debugging tools. It was somewhat ironic, because the application we were building was essentially supposed to do exactly that. I.e. a bunch of the tools probably existed, because there were holes in what our real application offered.

So, as much as makes sense, we should strive to integrate tooling like this directly into the application.
It's essentially a matter of asking the question: Is this something that "normal" users might also appreciate?
Or: Would this empower "normal" users to solve problems themselves and decrease the support burden?

Obviously, that looks different with every debugging tool. Some tools are for understanding how something got broken/invalid. Others are for understanding how an object got into its current (valid) state.

At least some of the things on your list probably belong in the application e.g.:

• get snapshot at a point in time
• replay changes / make object from scratch and compare with current snapshot

[hahn-kev]

That's fair, though in this case there's value in pealing away some layers, and I don't think that will be as useful to users after that (not that I want to hide this from them).

For example the snapshot at a point in time, a user would need to have a fully working project and the user would want to render the object in a GUI. For IT support we could imagine them getting a project which won't open and they actually don't want the object hidden under a UI, they just want the raw JSON. Replaying changes, again similar thing, give it an object ID and it would maybe replay all changes and output a snapshot as JSON to the console or something, then support could look at the log and see where something went wrong and by showing as much raw data as possible they can try to figure out what's going on.

In thinking through that above I think the biggest benefit of building something separate is that we can try our best to make it work with any project, even if it's broken. That's much harder to do in the app as just opening a project will query a lot of state and if something is broken there's not a lot you can do (we can improve that, but it's really hard to anticipate and maybe not even worth it). That said a lot of the stuff we build for a debugging tool would still be useful inside the app.