Un-doing changes

I'd love to help you, but I can't figure out what you are asking.

There are all sorts of ways to roll-back changes, and some of these allow re-running the changes, branching your changesets, merging those branches again, etc.

But I can't work out if you are looking for something for the Windows registry, Windows in general, databases, settings in some software, code for embedded systems, etc.

As a general point, if it helps you, then the best way to help people identify changes they want to undo is to find a way to identify what the changes did in the first place. For example, you might require people to add a log message saying why the change was made.

I'm trying to figure out how you, as an organic being, think about and "remember" The Past and, in particular, points *in* the past. (grrr... that's vague, too....)

E.g., the references to Windows are meant to point out that this sort of provision exists -- in some form (apparently) -- in that/those products. So, hopefully people who have *used* them EFFECTIVELY could identify with how that feature helped them do these roll-backs.

I.e., did you EXPLICITLY identify a point in time that you wanted to preserve, perform some action, make a note of that "event" so that you could later roll-back to that point?

E.g., when I build a new system, I image the disk at various steps along the process so that if I botch a later step, I can revert to a "good" previous step -- without having to repeat everything that came before. In this case, I am taking deliberate actions -- deciding *when* to image the drive(s), actually imaging them, preserving the images, making notes of what they "mean"/represent, etc.

My *Goal* is a mechanism that helps do this for the user "automatically" (embedded product, not "windows"). So, I want to understand how "similar" (though not equivalent) mechanisms are used to be able to extrapolate enough information to develop a useful algorithm.

Again returning to my imaging example... if something automatically imaged the drive for me after each piece of software was installed, I would look back over a log of what-was-installed-when and decide how far to roll back ("Everything was working fine until I installed Gonkulator9000")

The technology isn't the issue. Rather, the "psychology" (?) is. How do people "think" about things.

For example, noting times of changes is an aid because it lets the user think about when the "problem" (or "less desirable behavior") likely occurred (e.g., a change three weeks ago is probably not germane to something happening "recently"). Likewise, changes tend to happen in groups (even if size of group is "1" :> ). So, identifying (algorithmically) those "groups" -- so they can be regarded as fat "events" would probably help the user ("Ah, this was when I changed the background wallpaper and that's when this *other* change happened as well -- so it must be something in this group of changes...")

I think that gets cumbersome and will lead to lots of messages like "Changed" :> My current thinking is a "thesaurus" of sorts that lets me (at design time) tie keywords to settings and then lets the user "search" the audit log for changes related to those keywords. (presumably, you aren't interested in things that did NOT change yet match the keywords).

Yes, I have lots of check-ins to my source code system with log messages like "small changes", "bug fix", "check in for today". But sometimes I use useful messages.

Other than that, I think the most common identification for a change to undo is simply "the last thing I did".

Time and/or date is definitely useful for identifying changes - both absolute timestamps, and relative to the current time ("yesterday", "last week", etc.).

If you are trying to get some automatic system that doesn't rely too much on explicit log messages from users, then also try to log what else happened at the same time - "the changes made when installing program X", etc.

I don't know if that is the remotest help to you, but I think you are asking vague questions with even vaguer answers - if there are any answers at all.

Now consider that sort of remedy when dealing with a *device* (not a desktop system where typing is "convenient" and just laziness discourages effective messaging). E.g., if you had made a change to some aspect of your automobile's control system "while driving" that, later, you might want to undo...

I think this is the easiest thing to deal with. It has more "immediacy" associated with it -- still fresh in your mind, even if it was days ago, etc.

Yes, I think this is important. *Not* just "what other CHANGES were made" at the same time but else was being *done* at the same time.

Of course, for devices, it's not as easy as a desktop machine to simply log which commands were executed (which programs were run) since often it's one "program" running continuously...

I am finding the biggest challenges to be understanding how people

E.g., if it was a phone you were involved with, then the calls that you placed/received would be significant events that framed your interaction with the device: "I did this just after that call from Bob..."