<div><div dir="auto">Good explain why do not use  .cs</div><div dir="auto">Realize don’t think in a collaborative system versus a one man ruling all.</div><div dir="auto"><br></div><br><div class="gmail_quote"><div dir="ltr">On Sun, 22 Jul 2018 at 19:01 Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2018-07-22 17:17 GMT+02:00 Edgar De Cleene <span dir="ltr"><<a href="mailto:edgardec2005@gmail.com" target="_blank">edgardec2005@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Could send this to Cuis list ?<div>Like what Juan have to said.</div><div><div class="m_-99112961520051657gmail-h5"><div><br></div></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>If you look at <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/CodeManagementInCuis.md" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/CodeManagementInCuis.md</a><br></div><div>you will see that package had to be introduced in Cuis for easing contributions.<br></div><div>Why packages are not managed with change set? Because it would not scale...</div><div>They are handled by git/github.</div><div><br></div><div>Then there is a big ball called Cuis Core which is thus kind of special package still managed with change set...</div><div><br></div><div>First, I ask you: how many people can integrate the change set in the core image apart Juan?</div><div>See for example, when by miracle a change set is integrated immediately (otherwise it would have to change update number),</div><div><a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blame/master/CoreUpdates/3369-Make-SmalltalkEditorMenu-dynamic-HernanWilkinson-2018Jul10-18h51m-HAW.1.cs.st" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blame/master/CoreUpdates/3369-Make-SmalltalkEditorMenu-dynamic-HernanWilkinson-2018Jul10-18h51m-HAW.1.cs.st</a></div><div>Even if not written by Juan, it is integrated by Juan.</div><div>And you see a linear history without branches in the update numbers. But pull requests are not necessarily linear.</div><div>It means that Juan so far deploy efforts to sort out the changes and integrate them.</div><div>It also fits well his volunty to control Cuis.</div><div>You see that Cuis is an exact example of <a href="https://en.wikipedia.org/wiki/Benevolent_dictatorship" target="_blank">https://en.wikipedia.org/wiki/Benevolent_dictatorship</a>.<br></div><div>It's not our model in Squeak.<br></div><div><br></div><div>Second, I maintain that it would not scale for us.</div><div>There are 14 contributors in <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors</a><br></div><div>and 81 closed pull request in <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls</a>,</div><div>and only a subset of them concerning change sets.</div><div>So probably not many conflicts so far.</div><div>Please compare to how many package versions in Squeak inbox and treated inbox.</div><div><br></div><div>Third, what if I forked <a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates</a></div><div>and made several changes, some accepted and integrated by Juan, but with a different update number, some yet not integrated, some refused...</div><div>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.<br></div><div><br></div><div>Last, since there are packages, why do Cuis Core has to be handled specially?</div><div>Because of live updating. We use the image to change the image, so from time to time, special actions (scripts) are required for bootstrapping.</div><div>A good example is changing compiler or core features in Morphic.<br></div><div>This is the main reason for keeping changeset: git does not have anything to offer for live update, git is designed for dead code.</div><div>So I guess that rather than inventing own new way to handle live update thru git <br></div><div>(it could mean something as complex as the Pharo bootstrapping efforts),</div><div>Juan preferred to keep the .cs like he always did when the project was single-manned.</div><div>This does not make .cs a good choice, just a default choice.<br></div><div><br></div><div>In Squeak we have same problem with live update.</div><div>We have to use the MonticelloConfigurationMap (MCM) for live updating the image.</div><div>These live-update mcm are numbered, like the CoreUpdates are numbered in Cuis.</div><div>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...<br></div><div><br></div><div>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!<br></div><div>And a second enormous difference: these mcm do not contain code. They only contain reference to package versions.<div>This is what enables the whole source code to be managed in a single way: Monticello packages.</div><div>This gives possibility to browse every method edition unlike .cs.<br></div></div><div>This also give the possibility to merge with local image modifications rather than overwrite like in Cuis<br></div><div> (though there is no guaranty that the bootstrap scripts will work in a modified image, like with .cs).</div><div><br></div><div>I don't want to discuss more the choices of Juan. They were done in a certain context that does not match ours.<br></div><div>He always refused to integrate MC for not bloating the Cuis image.<br></div><div>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.<br></div><div>The live update problem forced him to be conservative with .cs with a scope reduced to Core.</div><div>Given the smaller size of core code in Cuis and the benevolent dictatorship model, it may last.</div><div><br></div><div><div>I can tell you that I used both .cs and MC and would never go back. One is clearly superior.</div>For Squeak, .cs would be a big regression!<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="m_-99112961520051657gmail-h5"><div></div><div><br><div><br><blockquote type="cite"><div>On 22 Jul 2018, at 09:49, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</div><br class="m_-99112961520051657gmail-m_-6240180739958736754Apple-interchange-newline"><div><div dir="ltr"><div>Hi Edgar,</div><div>Yes, there are good reasons for not using .cs.</div><div>.cs do not scale. Or history has to be purely linear, which does not happen in real world.</div><div><div>Merging concurrent versions is impractical, or even impossible without a history of branches.</div><div></div></div><div>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!</div><div>Some features would take time to implement, and inevitably lead to conflicts.<br></div><div>We finally had to put version history in method/class comments (author+timestamp+reason of change).</div><div>A poor man source code versionning that bloated the source code with orthogonal information...</div><div><div class="gmail_extra"><br></div><div class="gmail_extra">I separated UpdateStream in own package in 2013 for the purpose of removing it, but this is unfinished work...</div><div class="gmail_extra">One has to check if there are not unique implementor sends leaking outside the package.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene <span dir="ltr"><<a href="mailto:edgardec2005@gmail.com" target="_blank">edgardec2005@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I wish we have .cs as in old days , but some people like using clumsy tools.<br>
So if we do not use .cs anymore why have UpdateStreamDownloader and related<br>
to lo download .cs from server ?<br>
<br>
<br>
Edgar<br>
@morplenauta<br>
<br>
<br>
<br>
</blockquote></div><br></div></div></div>
<br></div></blockquote></div><br></div></div></div></div><br><br>
<br></blockquote></div></div></div></blockquote></div></div>