<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-01 21:42 GMT+02:00 Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marcel,<br>
<span class=""><br>
> - Please refrain from committing unrelated changes that are easily to<br>
> separate. If you have troubles uploading the 1000K MCZ for the System<br>
<br>
</span>I do keep significant changes, which are unrelated to each other, to<br>
separate commits, however, I prefer to piggy-back my meaningless<br>
changes like color tweaks or comment typo's. The reason is, when I<br>
arrow through the MC history of a package, I only want to see<br>
*meaningful* changes, not dozens of meaningless tiny little fixes and<br>
roll-backs that don't need to be consumed later, therefore, don't need<br>
to be in their own commit.<br>
<br>
This isn't even about the heavyweightness and unscalability of MC,<br>
which is an issue in itself, but purely about having a dense and tidy<br>
MC history domain.<br>
<br>
MC is able to handle all the diffing, merging, backporting, etc. in<br>
spite of this. You didn't explain why you prefer to have thousands of<br>
micro versions...<br>
<span class=""><br></span></blockquote><div>Hi Chris,<br></div><div>the main reasons for using atomic commits:<br></div><div>The ability to review things - large blob of unrelated things are difficult to review<br></div><div>The ability to know which changes go together if we want to backport/revert a patch/feature<br></div><div> and eventually to cherry pick changes from one branch to another branch<br> (more a git feature than mc, but could be done in mc too).<br></div><div><br>Separation of concerns: putting different features into different commits is just like housekeeping,<br></div><div>like classifying classes in right categories and methods in right protocols...<br></div><div>This is not strictly necessary but help following the stream of changes.<br></div><div><br></div><div>At extreme level where branching is easy like git, one well accepted policy is to put each feature into a different branch.<br></div><div>In mc, where each parallel commit is in its own branch (no matter the naming conventions),<br>this is somehow what we do (or at least should do) when committing in inbox.<br></div><div>This does ease the work of integrating those changes.<br><br></div><div>Why should the policy be different in trunk?<br></div><br><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> - That "<a href="http://patch.st" rel="noreferrer" target="_blank">patch.st</a>" hack seems like an indication that there are several<br>
> situations where you cannot cope with the .image characteristics of the<br>
> Smalltalk system. Please think about a better solution because the .image<br>
> file should usually not be read-only. It impedes Smalltalk-style maintenance<br>
> of such an image. While there have been good reasons in the past for<br>
> treating the .image in the Etoys bundles as read-only and relying on project<br>
> import/explort, I do not agree that we should make such a specific case<br>
> common practice. This "<a href="http://patch.st" rel="noreferrer" target="_blank">patch.st</a>" feels like a first step towards yet another<br>
> CI/build system, which we already have with smalltalkCI and TravisCI.<br>
<br>
</span>I don't know how to respond to these comments other than -- yesterday<br>
when you spoke of avoiding the image from growing into a "beast" -- I<br>
totally agree and that's why, IMO, all Squeak-based servers should use<br>
this design, because that's what it does.<br>
<span class=""><br>
> - This commit message would benefit from a little more explanation. There is<br>
> plenty "what you did" but too little "why you did it". For example, the<br>
> words "... to be re-patched in the event of a restart" really need an<br>
> explanation of why you cannot just supply a start-up script to do that<br>
> patching like "./vm some.image <a href="http://patch.st" rel="noreferrer" target="_blank">patch.st</a>". Please invest more time in more<br>
> elaborate commit messages.<br>
<br>
</span>I think the issue is that I should write some documentation about<br>
making a Squeak server using this design. That's where the answer to<br>
such question would be found.. MC commits only should have enough<br>
information to understand the context of the *change*, i.e., "what's<br>
different", not any broader explanations of how the system works.<br>
<br>
BTW, the answer(s) to that question are: 1) because nearly every<br>
single script requires its own ".st" counterpart already, 2)<br>
daemontools runs the #run script, not #patch, and 3) I require to be<br>
able to ascertain exactly what I'm running in production from the<br>
command-line, without having RFB' into the image and start diffing the<br>
dirty MC packages in the production server...<br>
<br>
Best,<br>
Chris<br>
<br>
</blockquote></div><br></div></div>