I wish we have .cs as in old days , but some people like using clumsy tools. So if we do not use .cs anymore why have UpdateStreamDownloader and related to lo download .cs from server ?
Edgar @morplenauta
Hi Edgar, Yes, there are good reasons for not using .cs. .cs do not scale. Or history has to be purely linear, which does not happen in real world. Merging concurrent versions is impractical, or even impossible without a history of branches. I've used .cs for more than ten years in the 90s, and even with a team reduced to 3 persons, it was far from ideal! Some features would take time to implement, and inevitably lead to conflicts. We finally had to put version history in method/class comments (author+timestamp+reason of change). A poor man source code versionning that bloated the source code with orthogonal information...
I separated UpdateStream in own package in 2013 for the purpose of removing it, but this is unfinished work... One has to check if there are not unique implementor sends leaking outside the package.
2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene edgardec2005@gmail.com:
I wish we have .cs as in old days , but some people like using clumsy tools. So if we do not use .cs anymore why have UpdateStreamDownloader and related to lo download .cs from server ?
Edgar @morplenauta
Could send this to Cuis list ? Like what Juan have to said.
On 22 Jul 2018, at 09:49, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi Edgar, Yes, there are good reasons for not using .cs. .cs do not scale. Or history has to be purely linear, which does not happen in real world. Merging concurrent versions is impractical, or even impossible without a history of branches. I've used .cs for more than ten years in the 90s, and even with a team reduced to 3 persons, it was far from ideal! Some features would take time to implement, and inevitably lead to conflicts. We finally had to put version history in method/class comments (author+timestamp+reason of change). A poor man source code versionning that bloated the source code with orthogonal information...
I separated UpdateStream in own package in 2013 for the purpose of removing it, but this is unfinished work... One has to check if there are not unique implementor sends leaking outside the package.
2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene <edgardec2005@gmail.com mailto:edgardec2005@gmail.com>: I wish we have .cs as in old days , but some people like using clumsy tools. So if we do not use .cs anymore why have UpdateStreamDownloader and related to lo download .cs from server ?
Edgar @morplenauta
2018-07-22 17:17 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
Could send this to Cuis list ? Like what Juan have to said.
If you look at
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/C... you will see that package had to be introduced in Cuis for easing contributions. Why packages are not managed with change set? Because it would not scale... They are handled by git/github.
Then there is a big ball called Cuis Core which is thus kind of special package still managed with change set...
First, I ask you: how many people can integrate the change set in the core image apart Juan? See for example, when by miracle a change set is integrated immediately (otherwise it would have to change update number), https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blame/master/CoreUpdate... Even if not written by Juan, it is integrated by Juan. And you see a linear history without branches in the update numbers. But pull requests are not necessarily linear. It means that Juan so far deploy efforts to sort out the changes and integrate them. It also fits well his volunty to control Cuis. You see that Cuis is an exact example of https://en.wikipedia.org/wiki/Benevolent_dictatorship. It's not our model in Squeak.
Second, I maintain that it would not scale for us. There are 14 contributors in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors and 81 closed pull request in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls, and only a subset of them concerning change sets. So probably not many conflicts so far. Please compare to how many package versions in Squeak inbox and treated inbox.
Third, what if I forked https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates and made several changes, some accepted and integrated by Juan, but with a different update number, some yet not integrated, some refused... How am i supposed to merge? That's the manual handling of change sets that typically is difficult and error prone, and that I don't want to live with anymore.
Last, since there are packages, why do Cuis Core has to be handled specially? Because of live updating. We use the image to change the image, so from time to time, special actions (scripts) are required for bootstrapping. A good example is changing compiler or core features in Morphic. This is the main reason for keeping changeset: git does not have anything to offer for live update, git is designed for dead code. So I guess that rather than inventing own new way to handle live update thru git (it could mean something as complex as the Pharo bootstrapping efforts), Juan preferred to keep the .cs like he always did when the project was single-manned. This does not make .cs a good choice, just a default choice.
In Squeak we have same problem with live update. We have to use the MonticelloConfigurationMap (MCM) for live updating the image. These live-update mcm are numbered, like the CoreUpdates are numbered in Cuis. They have to be loaded/merged in sequence because of bootstrap scripts, and thus cannot be applied in arbitrary orders which severely limit the opened branching model of git...
But a big difference with Cuis is that a new MCM is emitted if and only if a bootstrap srcipt is necessary, not for every core change! And a second enormous difference: these mcm do not contain code. They only contain reference to package versions. This is what enables the whole source code to be managed in a single way: Monticello packages. This gives possibility to browse every method edition unlike .cs. This also give the possibility to merge with local image modifications rather than overwrite like in Cuis (though there is no guaranty that the bootstrap scripts will work in a modified image, like with .cs).
I don't want to discuss more the choices of Juan. They were done in a certain context that does not match ours. He always refused to integrate MC for not bloating the Cuis image. The will to be present on github guided him to this package solution, in this context Monticello could be viewed more as an obstacle than a solution. The live update problem forced him to be conservative with .cs with a scope reduced to Core. Given the smaller size of core code in Cuis and the benevolent dictatorship model, it may last.
I can tell you that I used both .cs and MC and would never go back. One is clearly superior. For Squeak, .cs would be a big regression!
On 22 Jul 2018, at 09:49, Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com> wrote:
Hi Edgar, Yes, there are good reasons for not using .cs. .cs do not scale. Or history has to be purely linear, which does not happen in real world. Merging concurrent versions is impractical, or even impossible without a history of branches. I've used .cs for more than ten years in the 90s, and even with a team reduced to 3 persons, it was far from ideal! Some features would take time to implement, and inevitably lead to conflicts. We finally had to put version history in method/class comments (author+timestamp+reason of change). A poor man source code versionning that bloated the source code with orthogonal information...
I separated UpdateStream in own package in 2013 for the purpose of removing it, but this is unfinished work... One has to check if there are not unique implementor sends leaking outside the package.
2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene edgardec2005@gmail.com:
I wish we have .cs as in old days , but some people like using clumsy tools. So if we do not use .cs anymore why have UpdateStreamDownloader and related to lo download .cs from server ?
Edgar @morplenauta
Good explain why do not use .cs Realize don’t think in a collaborative system versus a one man ruling all.
On Sun, 22 Jul 2018 at 19:01 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2018-07-22 17:17 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
Could send this to Cuis list ? Like what Juan have to said.
If you look at
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/C... you will see that package had to be introduced in Cuis for easing contributions. Why packages are not managed with change set? Because it would not scale... They are handled by git/github.
Then there is a big ball called Cuis Core which is thus kind of special package still managed with change set...
First, I ask you: how many people can integrate the change set in the core image apart Juan? See for example, when by miracle a change set is integrated immediately (otherwise it would have to change update number),
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blame/master/CoreUpdate... Even if not written by Juan, it is integrated by Juan. And you see a linear history without branches in the update numbers. But pull requests are not necessarily linear. It means that Juan so far deploy efforts to sort out the changes and integrate them. It also fits well his volunty to control Cuis. You see that Cuis is an exact example of https://en.wikipedia.org/wiki/Benevolent_dictatorship. It's not our model in Squeak.
Second, I maintain that it would not scale for us. There are 14 contributors in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors and 81 closed pull request in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls, and only a subset of them concerning change sets. So probably not many conflicts so far. Please compare to how many package versions in Squeak inbox and treated inbox.
Third, what if I forked https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates and made several changes, some accepted and integrated by Juan, but with a different update number, some yet not integrated, some refused... How am i supposed to merge? That's the manual handling of change sets that typically is difficult and error prone, and that I don't want to live with anymore.
Last, since there are packages, why do Cuis Core has to be handled specially? Because of live updating. We use the image to change the image, so from time to time, special actions (scripts) are required for bootstrapping. A good example is changing compiler or core features in Morphic. This is the main reason for keeping changeset: git does not have anything to offer for live update, git is designed for dead code. So I guess that rather than inventing own new way to handle live update thru git (it could mean something as complex as the Pharo bootstrapping efforts), Juan preferred to keep the .cs like he always did when the project was single-manned. This does not make .cs a good choice, just a default choice.
In Squeak we have same problem with live update. We have to use the MonticelloConfigurationMap (MCM) for live updating the image. These live-update mcm are numbered, like the CoreUpdates are numbered in Cuis. They have to be loaded/merged in sequence because of bootstrap scripts, and thus cannot be applied in arbitrary orders which severely limit the opened branching model of git...
But a big difference with Cuis is that a new MCM is emitted if and only if a bootstrap srcipt is necessary, not for every core change! And a second enormous difference: these mcm do not contain code. They only contain reference to package versions. This is what enables the whole source code to be managed in a single way: Monticello packages. This gives possibility to browse every method edition unlike .cs. This also give the possibility to merge with local image modifications rather than overwrite like in Cuis (though there is no guaranty that the bootstrap scripts will work in a modified image, like with .cs).
I don't want to discuss more the choices of Juan. They were done in a certain context that does not match ours. He always refused to integrate MC for not bloating the Cuis image. The will to be present on github guided him to this package solution, in this context Monticello could be viewed more as an obstacle than a solution. The live update problem forced him to be conservative with .cs with a scope reduced to Core. Given the smaller size of core code in Cuis and the benevolent dictatorship model, it may last.
I can tell you that I used both .cs and MC and would never go back. One is clearly superior. For Squeak, .cs would be a big regression!
On 22 Jul 2018, at 09:49, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Edgar, Yes, there are good reasons for not using .cs. .cs do not scale. Or history has to be purely linear, which does not happen in real world. Merging concurrent versions is impractical, or even impossible without a history of branches. I've used .cs for more than ten years in the 90s, and even with a team reduced to 3 persons, it was far from ideal! Some features would take time to implement, and inevitably lead to conflicts. We finally had to put version history in method/class comments (author+timestamp+reason of change). A poor man source code versionning that bloated the source code with orthogonal information...
I separated UpdateStream in own package in 2013 for the purpose of removing it, but this is unfinished work... One has to check if there are not unique implementor sends leaking outside the package.
2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene edgardec2005@gmail.com:
I wish we have .cs as in old days , but some people like using clumsy tools. So if we do not use .cs anymore why have UpdateStreamDownloader and related to lo download .cs from server ?
Edgar @morplenauta
So is the outcome of this discussion that UpdateStreamDownloader should be removed?
On 7/23/18, Edgar De Cleene edgardec2005@gmail.com wrote:
Good explain why do not use .cs Realize don’t think in a collaborative system versus a one man ruling all.
On Sun, 22 Jul 2018 at 19:01 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2018-07-22 17:17 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
Could send this to Cuis list ? Like what Juan have to said.
If you look at
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/C... you will see that package had to be introduced in Cuis for easing contributions. Why packages are not managed with change set? Because it would not scale... They are handled by git/github.
Then there is a big ball called Cuis Core which is thus kind of special package still managed with change set...
First, I ask you: how many people can integrate the change set in the core image apart Juan? See for example, when by miracle a change set is integrated immediately (otherwise it would have to change update number),
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blame/master/CoreUpdate... Even if not written by Juan, it is integrated by Juan. And you see a linear history without branches in the update numbers. But pull requests are not necessarily linear. It means that Juan so far deploy efforts to sort out the changes and integrate them. It also fits well his volunty to control Cuis. You see that Cuis is an exact example of https://en.wikipedia.org/wiki/Benevolent_dictatorship. It's not our model in Squeak.
Second, I maintain that it would not scale for us. There are 14 contributors in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors and 81 closed pull request in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls, and only a subset of them concerning change sets. So probably not many conflicts so far. Please compare to how many package versions in Squeak inbox and treated inbox.
Third, what if I forked https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates and made several changes, some accepted and integrated by Juan, but with a different update number, some yet not integrated, some refused... How am i supposed to merge? That's the manual handling of change sets that typically is difficult and error prone, and that I don't want to live with anymore.
Last, since there are packages, why do Cuis Core has to be handled specially? Because of live updating. We use the image to change the image, so from time to time, special actions (scripts) are required for bootstrapping. A good example is changing compiler or core features in Morphic. This is the main reason for keeping changeset: git does not have anything to offer for live update, git is designed for dead code. So I guess that rather than inventing own new way to handle live update thru git (it could mean something as complex as the Pharo bootstrapping efforts), Juan preferred to keep the .cs like he always did when the project was single-manned. This does not make .cs a good choice, just a default choice.
In Squeak we have same problem with live update. We have to use the MonticelloConfigurationMap (MCM) for live updating the image. These live-update mcm are numbered, like the CoreUpdates are numbered in Cuis. They have to be loaded/merged in sequence because of bootstrap scripts, and thus cannot be applied in arbitrary orders which severely limit the opened branching model of git...
But a big difference with Cuis is that a new MCM is emitted if and only if a bootstrap srcipt is necessary, not for every core change! And a second enormous difference: these mcm do not contain code. They only contain reference to package versions. This is what enables the whole source code to be managed in a single way: Monticello packages. This gives possibility to browse every method edition unlike .cs. This also give the possibility to merge with local image modifications rather than overwrite like in Cuis (though there is no guaranty that the bootstrap scripts will work in a modified image, like with .cs).
I don't want to discuss more the choices of Juan. They were done in a certain context that does not match ours. He always refused to integrate MC for not bloating the Cuis image. The will to be present on github guided him to this package solution, in this context Monticello could be viewed more as an obstacle than a solution. The live update problem forced him to be conservative with .cs with a scope reduced to Core. Given the smaller size of core code in Cuis and the benevolent dictatorship model, it may last.
I can tell you that I used both .cs and MC and would never go back. One is clearly superior. For Squeak, .cs would be a big regression!
On 22 Jul 2018, at 09:49, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Edgar, Yes, there are good reasons for not using .cs. .cs do not scale. Or history has to be purely linear, which does not happen in real world. Merging concurrent versions is impractical, or even impossible without a history of branches. I've used .cs for more than ten years in the 90s, and even with a team reduced to 3 persons, it was far from ideal! Some features would take time to implement, and inevitably lead to conflicts. We finally had to put version history in method/class comments (author+timestamp+reason of change). A poor man source code versionning that bloated the source code with orthogonal information...
I separated UpdateStream in own package in 2013 for the purpose of removing it, but this is unfinished work... One has to check if there are not unique implementor sends leaking outside the package.
2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene edgardec2005@gmail.com:
I wish we have .cs as in old days , but some people like using clumsy tools. So if we do not use .cs anymore why have UpdateStreamDownloader and related to lo download .cs from server ?
Edgar @morplenauta
On Mon, Jul 23, 2018 at 12:27:05PM +0200, H. Hirzel wrote:
So is the outcome of this discussion that UpdateStreamDownloader should be removed?
I would be happy just to see UpdateStreamDownloader get a good class comment that explains what it is, and that clarifies the difference between our current Montecello based update stream and the older change set based stream.
An update stream is not a version control system. The update stream that we use today happens to be built on top of Montecello, but if we ever wanted to decouple the update stream from the version control system (for example, if someone wanted to use git for version control), then it might be important to have a simple change set based mechanism that works independent of the version control systems.
I can also imagine a scenario in which we would want to provide some kind of "mirror" of Squeak trunk on GitHub in order to make the system more visible and accessible to the world at large. In that case, it might be helpful to have a change set based update stream that follows the real one in Montecello.
Dave
We do not currently use the UpdateStreamDownloader mechanism, but I think it is import
On 7/23/18, Edgar De Cleene edgardec2005@gmail.com wrote:
Good explain why do not use .cs Realize don???t think in a collaborative system versus a one man ruling all.
On Sun, 22 Jul 2018 at 19:01 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2018-07-22 17:17 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
Could send this to Cuis list ? Like what Juan have to said.
If you look at
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/C... you will see that package had to be introduced in Cuis for easing contributions. Why packages are not managed with change set? Because it would not scale... They are handled by git/github.
Then there is a big ball called Cuis Core which is thus kind of special package still managed with change set...
First, I ask you: how many people can integrate the change set in the core image apart Juan? See for example, when by miracle a change set is integrated immediately (otherwise it would have to change update number),
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blame/master/CoreUpdate... Even if not written by Juan, it is integrated by Juan. And you see a linear history without branches in the update numbers. But pull requests are not necessarily linear. It means that Juan so far deploy efforts to sort out the changes and integrate them. It also fits well his volunty to control Cuis. You see that Cuis is an exact example of https://en.wikipedia.org/wiki/Benevolent_dictatorship. It's not our model in Squeak.
Second, I maintain that it would not scale for us. There are 14 contributors in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors and 81 closed pull request in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls, and only a subset of them concerning change sets. So probably not many conflicts so far. Please compare to how many package versions in Squeak inbox and treated inbox.
Third, what if I forked https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates and made several changes, some accepted and integrated by Juan, but with a different update number, some yet not integrated, some refused... How am i supposed to merge? That's the manual handling of change sets that typically is difficult and error prone, and that I don't want to live with anymore.
Last, since there are packages, why do Cuis Core has to be handled specially? Because of live updating. We use the image to change the image, so from time to time, special actions (scripts) are required for bootstrapping. A good example is changing compiler or core features in Morphic. This is the main reason for keeping changeset: git does not have anything to offer for live update, git is designed for dead code. So I guess that rather than inventing own new way to handle live update thru git (it could mean something as complex as the Pharo bootstrapping efforts), Juan preferred to keep the .cs like he always did when the project was single-manned. This does not make .cs a good choice, just a default choice.
In Squeak we have same problem with live update. We have to use the MonticelloConfigurationMap (MCM) for live updating the image. These live-update mcm are numbered, like the CoreUpdates are numbered in Cuis. They have to be loaded/merged in sequence because of bootstrap scripts, and thus cannot be applied in arbitrary orders which severely limit the opened branching model of git...
But a big difference with Cuis is that a new MCM is emitted if and only if a bootstrap srcipt is necessary, not for every core change! And a second enormous difference: these mcm do not contain code. They only contain reference to package versions. This is what enables the whole source code to be managed in a single way: Monticello packages. This gives possibility to browse every method edition unlike .cs. This also give the possibility to merge with local image modifications rather than overwrite like in Cuis (though there is no guaranty that the bootstrap scripts will work in a modified image, like with .cs).
I don't want to discuss more the choices of Juan. They were done in a certain context that does not match ours. He always refused to integrate MC for not bloating the Cuis image. The will to be present on github guided him to this package solution, in this context Monticello could be viewed more as an obstacle than a solution. The live update problem forced him to be conservative with .cs with a scope reduced to Core. Given the smaller size of core code in Cuis and the benevolent dictatorship model, it may last.
I can tell you that I used both .cs and MC and would never go back. One is clearly superior. For Squeak, .cs would be a big regression!
On 22 Jul 2018, at 09:49, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Edgar, Yes, there are good reasons for not using .cs. .cs do not scale. Or history has to be purely linear, which does not happen in real world. Merging concurrent versions is impractical, or even impossible without a history of branches. I've used .cs for more than ten years in the 90s, and even with a team reduced to 3 persons, it was far from ideal! Some features would take time to implement, and inevitably lead to conflicts. We finally had to put version history in method/class comments (author+timestamp+reason of change). A poor man source code versionning that bloated the source code with orthogonal information...
I separated UpdateStream in own package in 2013 for the purpose of removing it, but this is unfinished work... One has to check if there are not unique implementor sends leaking outside the package.
2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene edgardec2005@gmail.com:
I wish we have .cs as in old days , but some people like using clumsy tools. So if we do not use .cs anymore why have UpdateStreamDownloader and related to lo download .cs from server ?
Edgar @morplenauta
One idea covering both The trunk , 5.2 and beyond is the master Each person start forking and have his own .image The changes each person have was saved somewhere And the number is
Edgar 1.cs David 1.cs Nicolas 1.cs This way, each squeaker become his ruler And any could have changes of others. Could have some stats of owner.nnnn.cs And kind of competition of popular ones.
On 23 Jul 2018, at 09:51, David T. Lewis lewis@mail.msen.com wrote:
I would be happy just to see UpdateStreamDownloader get a good class comment that explains what it is, and that clarifies the difference between our current Montecello based update stream and the older change set based stream.
An update stream is not a version control system. The update stream that we use today happens to be built on top of Montecello, but if we ever wanted to decouple the update stream from the version control system (for example, if someone wanted to use git for version control), then it might be important to have a simple change set based mechanism that works independent of the version control systems.
I can also imagine a scenario in which we would want to provide some kind of "mirror" of Squeak trunk on GitHub in order to make the system more visible and accessible to the world at large. In that case, it might be helpful to have a change set based update stream that follows the real one in Montecello.
Dave
We do not currently use the UpdateStreamDownloader mechanism, but I think it is import
Hi David, Edgar,
2018-07-23 16:00 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
One idea covering both The trunk , 5.2 and beyond is the master Each person start forking and have his own .image The changes each person have was saved somewhere And the number is
Edgar 1.cs David 1.cs Nicolas 1.cs This way, each squeaker become his ruler And any could have changes of others. Could have some stats of owner.nnnn.cs And kind of competition of popular ones.
This is only a solution for forking, but won't work for merging...
On 23 Jul 2018, at 09:51, David T. Lewis lewis@mail.msen.com wrote:
I would be happy just to see UpdateStreamDownloader get a good class comment that explains what it is, and that clarifies the difference between our current Montecello based update stream and the older change set based stream.
By principle of encapsulation, a comment should not tell about the
implementation of another class. So if we need a comparison, it should lie somewhere else.
An update stream is not a version control system. The update stream that we
use today happens to be built on top of Montecello, but if we ever wanted to decouple the update stream from the version control system (for example, if someone wanted to use git for version control), then it might be important to have a simple change set based mechanism that works independent of the version control systems.
But if the update stream does not refer to the VCS, then we get an image
out of sync with the VCS which is an undesirable property. If we would switch to git or whatever, we should arrange to keep the link between image and git repository.
I can also imagine a scenario in which we would want to provide some kind of "mirror" of Squeak trunk on GitHub in order to make the system more visible and accessible to the world at large. In that case, it might be helpful to have a change set based update stream that follows the real one in Montecello.
If github is not the source but only a mirror, then we loose the
efficiency of github interface. And here again a change set is a bad solution for tracking changes, it does not fit git model of code: a change to a single method would be split across many different .cs like is the case for Cuis now. There is no way for git to figure out that different files represent a different edition of a single method. With .cs, it's like you want to impose the internal format of VCS (diff with a method granularity). Forget about .cs, the mourning period is over ;)
Dave
We do not currently use the UpdateStreamDownloader mechanism, but I think it is import
Why ? Each become his master I could take your Nicolas.32.cs and David.44.cs as long was useful. Become Edgar.14.cs and Edgar.15.cs. I talking about forks of trunk private. The merge occurred on trunk when/if someone send to inbox
Sent from my iPhone
On 23 Jul 2018, at 12:08, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi David, Edgar,
2018-07-23 16:00 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
One idea covering both The trunk , 5.2 and beyond is the master Each person start forking and have his own .image The changes each person have was saved somewhere And the number is
Edgar 1.cs David 1.cs Nicolas 1.cs This way, each squeaker become his ruler And any could have changes of others. Could have some stats of owner.nnnn.cs And kind of competition of popular ones.
This is only a solution for forking, but won't work for merging...
2018-07-23 17:37 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
Why ? Each become his master I could take your Nicolas.32.cs and David.44.cs as long was useful. Become Edgar.14.cs and Edgar.15.cs. I talking about forks of trunk private. The merge occurred on trunk when/if someone send to inbox
Sure, you can copy and rename files. Then next time you want to merge, you just have to perform O(N^2) diff...
Sent from my iPhone
On 23 Jul 2018, at 12:08, Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com> wrote:
Hi David, Edgar,
2018-07-23 16:00 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
One idea covering both The trunk , 5.2 and beyond is the master Each person start forking and have his own .image The changes each person have was saved somewhere And the number is
Edgar 1.cs David 1.cs Nicolas 1.cs This way, each squeaker become his ruler And any could have changes of others. Could have some stats of owner.nnnn.cs And kind of competition of popular ones.
This is only a solution for forking, but won't work for merging...
On Mon, Jul 23, 2018 at 8:18 PM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2018-07-23 17:37 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
Why ? Each become his master I could take your Nicolas.32.cs and David.44.cs as long was useful. Become Edgar.14.cs and Edgar.15.cs. I talking about forks of trunk private. The merge occurred on trunk when/if someone send to inbox
Sure, you can copy and rename files. Then next time you want to merge, you just have to perform O(N^2) diff...
+1
Best, Karl
Sent from my iPhone
On 23 Jul 2018, at 12:08, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi David, Edgar,
2018-07-23 16:00 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
One idea covering both The trunk , 5.2 and beyond is the master Each person start forking and have his own .image The changes each person have was saved somewhere And the number is
Edgar 1.cs David 1.cs Nicolas 1.cs This way, each squeaker become his ruler And any could have changes of others. Could have some stats of owner.nnnn.cs And kind of competition of popular ones.
This is only a solution for forking, but won't work for merging...
2018-07-23 20:18 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2018-07-23 17:37 GMT+02:00 Edgar De Cleene edgardec2005@gmail.com:
Why ? Each become his master I could take your Nicolas.32.cs and David.44.cs as long was useful. Become Edgar.14.cs and Edgar.15.cs. I talking about forks of trunk private. The merge occurred on trunk when/if someone send to inbox
Sure, you can copy and rename files. Then next time you want to merge, you just have to perform O(N^2) diff...
This deserves more explanations: O(N^2) is if you want to use VCS to merge.
That's because the source code of each method can be in each .cs... It's just impossible.
If you don't use VCS for storing the .cs, then you get the problem of not having the history of the method. You diff from your image, find a difference, but you don't know if this is a fork from an older common ancestor...
And since the model you describe is just cherry picking, then you have examine if you reject or accept it, and redo this each time you want to merge...
And you also lost the ordering of changes which was the only interesting part of .cs.
How could this scale?
OK. Forget .cs How git could help us ? Which master repo and several cloned (how much people wish his own Squeak ? ) I open to new things and realize is 2018 now not 1998 when Squeak was unique and cool.
In a ideal world.
We have a kernel as Pharo bootstrap try to made (or maybe they have ). An intermediate like Cuis An all purpose Squeak And a roadmap how to go from kernel to SuperSqueak
On 23 Jul 2018, at 15:45, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
How could this scale?
On Mon, Jul 23, 2018 at 05:08:57PM +0200, Nicolas Cellier wrote:
On 23 Jul 2018, at 09:51, David T. Lewis lewis@mail.msen.com wrote:
I would be happy just to see UpdateStreamDownloader get a good class comment that explains what it is, and that clarifies the difference between our current Montecello based update stream and the older change set based stream.
By principle of encapsulation, a comment should not tell about the implementation of another class. So if we need a comparison, it should lie somewhere else.
Fair enough. But I would still be happy if UpdateStreamDownloader could have a good class comment. Oops, I fear that I have just given myself an assignment ;-)
An update stream is not a version control system. The update stream that we
use today happens to be built on top of Montecello, but if we ever wanted to decouple the update stream from the version control system (for example, if someone wanted to use git for version control), then it might be important to have a simple change set based mechanism that works independent of the version control systems.
But if the update stream does not refer to the VCS, then we get an image out of sync with the VCS which is an undesirable property. If we would switch to git or whatever, we should arrange to keep the link between image and git repository.
Fully agree. I was thinking of a scenario in which the update stream is generated by, and is not a replacement for, the VCS.
I think that this has been done in the past with our MC based update stream. Maybe Andreas did it? Or Edgar? Sorry I do not remember.
For any VCS, including Monticello, if it is possible to implement an update stream with that VCS, then it must also be possible for an image that is being updated to keep track of its update history in the form of a list of change sets. And it should be possible for that list of change sets to be re-applied to another image to achieve that same end result.
Dave
I proud to work with Andreas once. Keep the mail exchange as treasure.
I have now in a Monticello modify. Made a numbered .cs from each trunk update. A way of keep my version and not the trunk one for all packages except Monticello. And off course my .sar inside Monticello . I skip Monticello update for this reason You could see a experimental list here: http://squeakros.org/updates/
Edgar @morplenauta
On 23/07/2018, 20:30, "David T. Lewis" lewis@mail.msen.com wrote:
Fully agree. I was thinking of a scenario in which the update stream is
generated by, and is not a replacement for, the VCS.
I think that this has
been done in the past with our MC based update
stream. Maybe Andreas did it?
Or Edgar? Sorry I do not remember.
For any VCS, including Monticello, if it
is possible to implement an
update stream with that VCS, then it must also be
possible for an image
that is being updated to keep track of its update
history in the form of
a list of change sets. And it should be possible for
that list of change
sets to be re-applied to another image to achieve that
same end result.
Dave
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Edgar De Cleene -
Edgar J. De Cleene
-
H. Hirzel -
karl ramberg -
Nicolas Cellier