<div dir="ltr"><div>It looks like its taking as long as 15 minutes to index a single VMMaker.oscog Version into Magma (see log output below).  With more than 3500 Versions in VMMaker, my guess is this could take another few weeks!<br></div><div><br></div><div>So, I suggest that we go ahead and cut over to the new image using only SSFilesystem.  I will run a separate Squeak VM process to finish loading the ss.magma database, when its done, we can switch back to the SSCompositeStorage, with SSFilesystem as the primary, and the SSMagma to provide the history.</div><div><br></div><div>This doesn&#39;t solve the problem of Ronie&#39;s PW not being reset in <a href="http://box4.squeak.org" target="_blank">box4.squeak.org</a> (unless, Bert, you did that).  However, it solves the problem of the system, when using a SSCompositeStorage, of needing to obtain the initial SSRepository instance upon startup from the SSMagma, which is currently still &quot;behind&quot;, until it finally catches up.</div><div><br></div><div>How does that sound?</div><div><br></div><div> - Chris</div><div><br></div>2016-09-03T17:59:20.018847+02:<wbr>00 VMMaker.oscog-eem.711 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T18:04:31.069556+02:<wbr>00 VMMaker-dtl.289 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T18:12:41.965925+02:<wbr>00 VMMaker.oscog-eem.1519 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T<b>18:13</b>:25.429452+02:<wbr>00 Cog-eem.288 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T<b>18:27</b>:22.797825+02:<wbr>00 VMMaker-IgorStasenko.55 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T18:38:28.835509+02:<wbr>00 VMMaker.oscog-eem.658 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T<b>18:44</b>:51.454197+02:<wbr>00 VMMaker.oscog-eem.85 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T<b>18:56</b>:21.111055+02:<wbr>00 VMMaker.oscog-eem.1193 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T19:02:42.47393+02:<wbr>00 VMMaker.oscog-tpr.291 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T<b>19:05</b>:53.865053+02:<wbr>00 VMMaker-tpr.53 of VMMaker --&gt; committed to ss.magma<br>2016-09-03T<b>19:21</b>:28.711418+02:<wbr>00 VMMaker.oscog-eem.149 of VMMaker --&gt; committed to ss.magma<br>....<div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 2, 2016 at 8:59 PM, Chris Muller <span dir="ltr">&lt;<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">After reconsidering, we should wait until the bulk load is complete<br>
because, when using the new dual repository (one SSFilesystem and one<br>
SSMagma) the code must choose the SSRepository loaded from Magma<br>
instead of the one loaded from &quot;data.obj&quot; because that&#39;s the object<br>
Magma monitors for changes.<br>
<br>
Unfortunately its taking a long time to tear open the VMMaker<br>
project&#39;s 17GB worth of MCZ&#39;s and examine every internal MCDefinition<br>
(which, VMMaker has a lot in each one) to see if its already been<br>
canonicalized.<br>
<br>
If we deploy before its done then, for the reason above, some of the<br>
Versions which have been committed since the bulk load began will not<br>
be seen until the bulk load finishes.<br>
<br>
I wish I would have put some kind progress indication somewhere; it<br>
only logs the filenames its working on at the time.<br>
<div><div><br>
On Fri, Sep 2, 2016 at 5:47 PM, Levente Uzonyi &lt;<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>&gt; wrote:<br>
&gt; On Fri, 2 Sep 2016, Chris Muller wrote:<br>
&gt;<br>
&gt;&gt; I wasn&#39;t planning to.  The metadata for versions will be captured via<br>
&gt;&gt; the recovery process.  The other parts of the model, not, but<br>
&gt;&gt; thankfully they don&#39;t change much.<br>
&gt;&gt;<br>
&gt;&gt; As far as the image and daemontools run system, I think we&#39;re ready to<br>
&gt;&gt; switch over any time, however, the only thing I&#39;m not sure about are<br>
&gt;&gt; how the community emails work.  I think I saw the packages email<br>
&gt;&gt; address in the SSRepository model, so maybe it will &quot;just work&quot;?  Do<br>
&gt;&gt; either you know whether any special server configurations are needed<br>
&gt;&gt; to be able to send SMTP mail?<br>
&gt;<br>
&gt;<br>
&gt; I suppose it&#39;s just a setting, so it may just work.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Sep 2, 2016 at 4:20 PM, Levente Uzonyi &lt;<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Let&#39;s not forget that Ronie Salgado is still waiting for his password,<br>
&gt;&gt;&gt; which<br>
&gt;&gt;&gt; we should give him asap.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Hi Levente, I looked up the other email to refresh my memory --<br>
&gt;&gt; SSEMailSubscription&gt;&gt;#writeHea<wbr>ders is apparently where it writes the<br>
&gt;&gt; &quot;Date:&quot; header, with this code:<br>
&gt;&gt;<br>
&gt;&gt; 1     stream nextPutAll: &#39;Date: &#39;;<br>
&gt;&gt; 2         nextPutAll: MailMessage dateStampNow;<br>
&gt;&gt; 3          nextPut: Character space;<br>
&gt;&gt; 4          nextPutAll: TimeZone default printHHMM;<br>
&gt;&gt; 5          cr.<br>
&gt;&gt;<br>
&gt;&gt; So do we just need to remove line 4?  I can commit that change and<br>
&gt;&gt; build a new image if that&#39;s the right thing to do..<br>
&gt;&gt;<br>
&gt;<br>
&gt; No, the problem is with fractions in the seconds. And that should already be<br>
&gt; fixed in the new image.<br>
&gt;<br>
&gt; Levente<br>
</div></div></blockquote></div><br></div></div>