Reversibility of Changes
Last updated at 12:53 pm UTC on 17 January 2006
By mistake, I loaded a change set from the "File List" which broke KomHTTP. So, I was in a need to reverse changes. Göran Krampe answered my questions in detail. I thought perhaps this would be useful information. Göran's notes italics.
Questions about Reversability of ChangeSets:
For lack of knowledge, I tried to load the change set both as "fileIn entire file" as well as "install into new changeset". Not sure what the difference is
The only difference AFAIK between those two actions is that the latter does it in a separate ChangeSet and the former reuses the current one, thus potentially mixing it up with the rest you have in that changeset.
I'd like to revert everything to from before those changes - is that possible?
I guess what I am asking is whether following are reversible:
- installing package from SqueakMap PackageLoader
Packages on SM are in different formats. If they are in Monticello
format then they should be "uninstallable" - but it is not an action
that is available yet in the package loader UI. The Monticello browser
might have it though.
Packages using changesets etc are not reversible in general, I mean -
you need to do manual work and since changesets can contain do its
(arbitrary code being run on file in) it can in theory be impossible.
- installing change set using "fileIn entire file"
- installing change set using "install into new changeset"
No difference between those two regarding reversability. Changesets are generally NOT reversible since they can contain do-its. But many/most changesets don't contain do-its so they could theoretically be reversible - well, if they also don't contain removals etc. Removals
could also be reversible using the changelog - but they could also NOT
be reversible (if the old version isn't in the changelog).
I went to the Change browser and tried to "destroy change set" which appeared to do it, but then noticed that all the KomHttp classes were left in the image, (looking from browser) which completely confused me.
Nah, that only wipes out the ChangeSet AFAIK. The changes are still in the system there.
You can consider a ChangeSet to be kinda like a patch file. Or a "tape
recording" of code modifications. Unfortunately ChangeSets are...
slightly weird. For example - the ChangeSet object only contains a
reference to the method you modified - not the version of the new
So if you modify a method, a reference gets added to the ChangeSet -
then you file out the changeset and the fileout will have the current
version of the method in it. Then let's say you create a new changeset
and modify the method again. If you now file out the old changeset you
will get a different fileout - with the current method instead of the
Well, ChangeSets are generally not reversible and they are also, because of for example the issue described above, pretty icky things to use for primary Squeak development. My advice is:
1. For your coding projects, use Monticello.
2. For bug fixes, enhancements etc to send to the list or other
developers, use ChangeSets. If you are working with someone using
Monticello then you can of course use Monticello instead.