My social distancing project - MCConfiguration maps with versioning, comments, and author timestamps.
An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
Sounds great! Thanks!
Well done with the backward compatibility -- I'm interested in learning more about how you accomplished that. I'm hopeful it's by a way that leaves open further potential upgrades in the future, too.
- Chris
On Tue, Apr 14, 2020 at 6:37 PM David T. Lewis lewis@mail.msen.com wrote:
An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
Hi Chris,
I'll tidy it up and put something in the inbox tomorrow. The backward compatibility amounts to tricking the existing MCM parser into ignoring additional entries in the array of configuration entries. I think that this can be further extended as needed, and I also added a version field that could be updated for future extensions.
Dave
On Tue, Apr 14, 2020 at 09:37:53PM -0500, Chris Muller wrote:
Sounds great! Thanks!
Well done with the backward compatibility -- I'm interested in learning more about how you accomplished that. I'm hopeful it's by a way that leaves open further potential upgrades in the future, too.
- Chris
On Tue, Apr 14, 2020 at 6:37 PM David T. Lewis lewis@mail.msen.com wrote:
An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
On second thought, I am going to just copy the whole thing into the inbox. If this goes to trunk, we can consolidate the versions into one update and move all of this to treated, but for now it may be easier to review the code if you can see my update history.
All changes are in package MonticelloConfigurations, with new unit tests in the Tests package. The updates that I will put into the inbox are:
MonticelloConfigurations-dtl.160 MonticelloConfigurations-dtl.161 MonticelloConfigurations-dtl.162 MonticelloConfigurations-dtl.163 MonticelloConfigurations-dtl.164 MonticelloConfigurations-dtl.165 Tests-dtl.430 Tests-dtl.431 Tests-dtl.432
Dave
On Wed, Apr 15, 2020 at 06:06:29PM -0400, David T. Lewis wrote:
Hi Chris,
I'll tidy it up and put something in the inbox tomorrow. The backward compatibility amounts to tricking the existing MCM parser into ignoring additional entries in the array of configuration entries. I think that this can be further extended as needed, and I also added a version field that could be updated for future extensions.
Dave
On Tue, Apr 14, 2020 at 09:37:53PM -0500, Chris Muller wrote:
Sounds great! Thanks!
Well done with the backward compatibility -- I'm interested in learning more about how you accomplished that. I'm hopeful it's by a way that leaves open further potential upgrades in the future, too.
- Chris
On Tue, Apr 14, 2020 at 6:37 PM David T. Lewis lewis@mail.msen.com wrote:
An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
I should mention that I made a couple of changes to the MCConfigurationBrowser configuration browsers. These are:
1) There is a new button labeled "Versions" that opens an explorer on the version history of an MCConfiguration. Each entry in the history list can be browsed by sending #browse to it in the explorer.
2) When an MCConfigurationBrowser is opened on an MCConfiguration, it always opens on a new #copyForEdit version of the configuration, with the prior version added to its history.
Those are the only changes that I made to the UI, but they seem to be sufficient for any use case that I can think of at the moment.
Dave
On Wed, Apr 15, 2020 at 07:55:08PM -0400, David T. Lewis wrote:
On second thought, I am going to just copy the whole thing into the inbox. If this goes to trunk, we can consolidate the versions into one update and move all of this to treated, but for now it may be easier to review the code if you can see my update history.
All changes are in package MonticelloConfigurations, with new unit tests in the Tests package. The updates that I will put into the inbox are:
MonticelloConfigurations-dtl.160 MonticelloConfigurations-dtl.161 MonticelloConfigurations-dtl.162 MonticelloConfigurations-dtl.163 MonticelloConfigurations-dtl.164 MonticelloConfigurations-dtl.165 Tests-dtl.430 Tests-dtl.431 Tests-dtl.432
Dave
On Wed, Apr 15, 2020 at 06:06:29PM -0400, David T. Lewis wrote:
Hi Chris,
I'll tidy it up and put something in the inbox tomorrow. The backward compatibility amounts to tricking the existing MCM parser into ignoring additional entries in the array of configuration entries. I think that this can be further extended as needed, and I also added a version field that could be updated for future extensions.
Dave
On Tue, Apr 14, 2020 at 09:37:53PM -0500, Chris Muller wrote:
Sounds great! Thanks!
Well done with the backward compatibility -- I'm interested in learning more about how you accomplished that. I'm hopeful it's by a way that leaves open further potential upgrades in the future, too.
- Chris
On Tue, Apr 14, 2020 at 6:37 PM David T. Lewis lewis@mail.msen.com wrote:
An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
Has anyone had a chance to take a look at this? I've made a comple of updates, so the current versions in the inbox are Tests-dtl.432 and MonticelloConfigurations-dtl.167.
I should note that these updates interoperate with the current SqueakSource servers without issue, but the servers will need to have their MonticelloConfigurations packages updated before they can render the MCM files in the new format. So the easiest way to test is with either a local file based repository, or with a Personal Squeaksource that has MonticelloConfigurations update from the inbox.
When browsing an MCConfiguration, click the "Versions" button to see comments, timestamps, and version history. I'm attaching a screen shot of an explorer on the versions to give a feel for the organization.
Comments and criticism welcome,
Dave
On Wed, Apr 15, 2020 at 08:27:10PM -0400, David T. Lewis wrote:
I should mention that I made a couple of changes to the MCConfigurationBrowser configuration browsers. These are:
- There is a new button labeled "Versions" that opens an explorer on
the version history of an MCConfiguration. Each entry in the history list can be browsed by sending #browse to it in the explorer.
- When an MCConfigurationBrowser is opened on an MCConfiguration, it
always opens on a new #copyForEdit version of the configuration, with the prior version added to its history.
Those are the only changes that I made to the UI, but they seem to be sufficient for any use case that I can think of at the moment.
Dave
On Wed, Apr 15, 2020 at 07:55:08PM -0400, David T. Lewis wrote:
On second thought, I am going to just copy the whole thing into the inbox. If this goes to trunk, we can consolidate the versions into one update and move all of this to treated, but for now it may be easier to review the code if you can see my update history.
All changes are in package MonticelloConfigurations, with new unit tests in the Tests package. The updates that I will put into the inbox are:
MonticelloConfigurations-dtl.160 MonticelloConfigurations-dtl.161 MonticelloConfigurations-dtl.162 MonticelloConfigurations-dtl.163 MonticelloConfigurations-dtl.164 MonticelloConfigurations-dtl.165 Tests-dtl.430 Tests-dtl.431 Tests-dtl.432
Dave
On Wed, Apr 15, 2020 at 06:06:29PM -0400, David T. Lewis wrote:
Hi Chris,
I'll tidy it up and put something in the inbox tomorrow. The backward compatibility amounts to tricking the existing MCM parser into ignoring additional entries in the array of configuration entries. I think that this can be further extended as needed, and I also added a version field that could be updated for future extensions.
Dave
On Tue, Apr 14, 2020 at 09:37:53PM -0500, Chris Muller wrote:
Sounds great! Thanks!
Well done with the backward compatibility -- I'm interested in learning more about how you accomplished that. I'm hopeful it's by a way that leaves open further potential upgrades in the future, too.
- Chris
On Tue, Apr 14, 2020 at 6:37 PM David T. Lewis lewis@mail.msen.com wrote:
An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
Hi Dave,
I won't have time to review the client/UI side in depth as soon as you would like, but will definitely make time to review any updates if you wish to make in the server code, source.squeak.org/ss, prior to deployment.
- Chris
On Sat, Apr 18, 2020 at 2:37 PM David T. Lewis lewis@mail.msen.com wrote:
Has anyone had a chance to take a look at this? I've made a comple of updates, so the current versions in the inbox are Tests-dtl.432 and MonticelloConfigurations-dtl.167.
I should note that these updates interoperate with the current SqueakSource servers without issue, but the servers will need to have their MonticelloConfigurations packages updated before they can render the MCM files in the new format. So the easiest way to test is with either a local file based repository, or with a Personal Squeaksource that has MonticelloConfigurations update from the inbox.
When browsing an MCConfiguration, click the "Versions" button to see comments, timestamps, and version history. I'm attaching a screen shot of an explorer on the versions to give a feel for the organization.
Comments and criticism welcome,
Dave
On Wed, Apr 15, 2020 at 08:27:10PM -0400, David T. Lewis wrote:
I should mention that I made a couple of changes to the
MCConfigurationBrowser
configuration browsers. These are:
- There is a new button labeled "Versions" that opens an explorer on
the version history of an MCConfiguration. Each entry in the history list can be browsed by sending #browse to it in the explorer.
- When an MCConfigurationBrowser is opened on an MCConfiguration, it
always opens on a new #copyForEdit version of the configuration, with the prior version added to its history.
Those are the only changes that I made to the UI, but they seem to be sufficient for any use case that I can think of at the moment.
Dave
On Wed, Apr 15, 2020 at 07:55:08PM -0400, David T. Lewis wrote:
On second thought, I am going to just copy the whole thing into the inbox. If this goes to trunk, we can consolidate the versions into one update and move all of this to treated, but for now it may be easier to review the code if you can see my update history.
All changes are in package MonticelloConfigurations, with new unit
tests
in the Tests package. The updates that I will put into the inbox are:
MonticelloConfigurations-dtl.160 MonticelloConfigurations-dtl.161 MonticelloConfigurations-dtl.162 MonticelloConfigurations-dtl.163 MonticelloConfigurations-dtl.164 MonticelloConfigurations-dtl.165 Tests-dtl.430 Tests-dtl.431 Tests-dtl.432
Dave
On Wed, Apr 15, 2020 at 06:06:29PM -0400, David T. Lewis wrote:
Hi Chris,
I'll tidy it up and put something in the inbox tomorrow. The backward compatibility amounts to tricking the existing MCM parser into
ignoring
additional entries in the array of configuration entries. I think
that
this can be further extended as needed, and I also added a version field that could be updated for future extensions.
Dave
On Tue, Apr 14, 2020 at 09:37:53PM -0500, Chris Muller wrote:
Sounds great! Thanks!
Well done with the backward compatibility -- I'm interested in
learning
more about how you accomplished that. I'm hopeful it's by a way
that
leaves open further potential upgrades in the future, too.
- Chris
On Tue, Apr 14, 2020 at 6:37 PM David T. Lewis <
lewis@mail.msen.com> wrote:
An MC update stream, such as the Squeak trunk update stream,
relies
on a sequence of update maps stored in a repository. The update
maps
(MCM files) do not retain information about their authors or the
time
and reason for committing the maps, and they do not retain change information if an existing update map is modified, as
occasionally
may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that
they
can be stored in a format that saves the additional version
information,
and that is still readable by any earlier Squeak image. Updated
images
can read and understand the version information, and will store
new MCM
updates with comments, author initials, time stamps, and version
history.
I have a working version of this in my own image. It seems to
work quite
well, although I think I need to spend some more time using it
before
suggesting it for general use. If there is in interest, I can
put a copy
in the inbox.
Dave
Thanks Chris :-)
Dave
On Sat, Apr 18, 2020 at 05:48:38PM -0500, Chris Muller wrote:
Hi Dave,
I won't have time to review the client/UI side in depth as soon as you would like, but will definitely make time to review any updates if you wish to make in the server code, source.squeak.org/ss, prior to deployment.
- Chris
On Sat, Apr 18, 2020 at 2:37 PM David T. Lewis lewis@mail.msen.com wrote:
Has anyone had a chance to take a look at this? I've made a comple of updates, so the current versions in the inbox are Tests-dtl.432 and MonticelloConfigurations-dtl.167.
If someone has some spare cycles to take a look at this, I would appreciate a review. I'd like to move this to trunk but I would like at least one other set of eyeballs on it before I do so.
Here is how to test:
1) Merge Tests-dtl.432 and MonticelloConfigurations-dtl.167 from the inbox into your image.
2) Run MCConfigurationTest tests if you want to see how it works.
3) Open a repository such as trunk or VMMaker, and browse one of the update maps (e.g. update-mt.466.mcm in the trunk repository).
4) Change something in the browser (update a dependency or something like that).
5) Click the save button, entering things as prompted. There will be an editor for providing a version comment. When you you get to the dialog for selecting a repository, pick a local directory based repository on your hard drive (do not save back to the trunk repo).
6) Find the new MCM that you just saved, and browse it.
7) The browser will have a "Versions" button on the button bar. Click that to open an explorer showing a list of the new version and of its predecessors. Each of these instances maintains its own list of prior versions, as well as the comment text, a timestamp, author initials, and a UUID. There is no user interface for this, but an explorer is sufficient to show the version history.
8) From your local directory based repository, try browsing and saving the MCM a couple more times, and explore the resulting history lists.
9) Using an image that does /not/ have MonticelloConfigurations-dtl.167 installed, try opening and browsing one of the extended MCM files that you saved in your local directory based repository. They should look exactly as you would normally see, with no version history, comments, or author information.
10) Reply back to the list and say what you think.
Note that you should not expect a great user interface experience. This might be the subject of a future update, but for now we just need something that works.
Thank you!
Dave
On Sat, Apr 18, 2020 at 03:37:15PM -0400, David T. Lewis wrote:
Has anyone had a chance to take a look at this? I've made a comple of updates, so the current versions in the inbox are Tests-dtl.432 and MonticelloConfigurations-dtl.167.
I should note that these updates interoperate with the current SqueakSource servers without issue, but the servers will need to have their MonticelloConfigurations packages updated before they can render the MCM files in the new format. So the easiest way to test is with either a local file based repository, or with a Personal Squeaksource that has MonticelloConfigurations update from the inbox.
When browsing an MCConfiguration, click the "Versions" button to see comments, timestamps, and version history. I'm attaching a screen shot of an explorer on the versions to give a feel for the organization.
Comments and criticism welcome,
Dave
On Wed, Apr 15, 2020 at 08:27:10PM -0400, David T. Lewis wrote:
I should mention that I made a couple of changes to the MCConfigurationBrowser configuration browsers. These are:
- There is a new button labeled "Versions" that opens an explorer on
the version history of an MCConfiguration. Each entry in the history list can be browsed by sending #browse to it in the explorer.
- When an MCConfigurationBrowser is opened on an MCConfiguration, it
always opens on a new #copyForEdit version of the configuration, with the prior version added to its history.
Those are the only changes that I made to the UI, but they seem to be sufficient for any use case that I can think of at the moment.
Dave
On Wed, Apr 15, 2020 at 07:55:08PM -0400, David T. Lewis wrote:
On second thought, I am going to just copy the whole thing into the inbox. If this goes to trunk, we can consolidate the versions into one update and move all of this to treated, but for now it may be easier to review the code if you can see my update history.
All changes are in package MonticelloConfigurations, with new unit tests in the Tests package. The updates that I will put into the inbox are:
MonticelloConfigurations-dtl.160 MonticelloConfigurations-dtl.161 MonticelloConfigurations-dtl.162 MonticelloConfigurations-dtl.163 MonticelloConfigurations-dtl.164 MonticelloConfigurations-dtl.165 Tests-dtl.430 Tests-dtl.431 Tests-dtl.432
Dave
On Wed, Apr 15, 2020 at 06:06:29PM -0400, David T. Lewis wrote:
Hi Chris,
I'll tidy it up and put something in the inbox tomorrow. The backward compatibility amounts to tricking the existing MCM parser into ignoring additional entries in the array of configuration entries. I think that this can be further extended as needed, and I also added a version field that could be updated for future extensions.
Dave
On Tue, Apr 14, 2020 at 09:37:53PM -0500, Chris Muller wrote:
Sounds great! Thanks!
Well done with the backward compatibility -- I'm interested in learning more about how you accomplished that. I'm hopeful it's by a way that leaves open further potential upgrades in the future, too.
- Chris
On Tue, Apr 14, 2020 at 6:37 PM David T. Lewis lewis@mail.msen.com wrote:
An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
On Tue, Apr 14, 2020 at 4:37 PM David T. Lewis lewis@mail.msen.com wrote:
An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
Yass! I should have done that in my original MCM hack, or at least or at least when configs became used more widely. Then again, TSTTCPW did indeed work for a long time :)
- Vanessa -
Hi Vanessa,
On Tue, Apr 14, 2020 at 08:16:07PM -0700, Vanessa Freudenberg wrote:
On Tue, Apr 14, 2020 at 4:37 PM David T. Lewis lewis@mail.msen.com wrote:
An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
Yass! I should have done that in my original MCM hack, or at least or at least when configs became used more widely. Then again, TSTTCPW did indeed work for a long time :)
Indeed it has served us very well for a long time.
One good hack deserves another, so you will be pleased to know that I have not added anything that might be misconstrued as elegant ;-)
Dave
Hi Dave.
Sounds very interesting! Please share. :-)
Best, Marcel Am 15.04.2020 01:37:10 schrieb David T. Lewis lewis@mail.msen.com: An MC update stream, such as the Squeak trunk update stream, relies on a sequence of update maps stored in a repository. The update maps (MCM files) do not retain information about their authors or the time and reason for committing the maps, and they do not retain change information if an existing update map is modified, as occasionally may be required to correct a problem in the update stream.
I have found a way to extend the MCM configurations such that they can be stored in a format that saves the additional version information, and that is still readable by any earlier Squeak image. Updated images can read and understand the version information, and will store new MCM updates with comments, author initials, time stamps, and version history.
I have a working version of this in my own image. It seems to work quite well, although I think I need to spend some more time using it before suggesting it for general use. If there is in interest, I can put a copy in the inbox.
Dave
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
David T. Lewis -
Marcel Taeumel -
Vanessa Freudenberg