We have added two new features to FileList. And we used SUnit, where possible, to test our code. Let's do a little houskeeping.
If we open up a "simple change sorter" we can see a small handfull of changed classes.
By convention, the date and original author name remain untouched. You could actually keep an edit history in the lower comments if needed.
"Change Set: FileList-mods
Date: 21 September 2002
Author: Stephan B. Wessels
Added a simple enhancement where the file name of the selected file
can be copied to the clipboard. There is an existing menu operation
which supports copying the whole file name path to the clipboard and
this was left alone. Also provided a way to copy a file from either a local
directory or a remote one to a local directory. No provision has been made to
copy a local file to the remote at this time, however."
We should also examine the change set contents to be sure we have what we intended. I tend to select each class in the change set and then review the methods identified, one-by-one.
The change set must record events like this. Imagine that we gave a copy of our previous change set, the one without this refactoring, to another Squeak developer. And then we handed this new version to that developer at a later time. If the new change set did not have this reference that the method was removed, then that person's development image would contain both the old method and our new one. So this is okay.
After this review of the change set we decide it's ready to go. You can choose "file out" from the change set menu.
Continue on to Unfinished Work to Consider.
Back to the beginning of this example.