<div dir="ltr">Hi Ben, Hi All,<div><br></div><div>    I&#39;m quite conservative when it comes to relying on others&#39; infrastructure so I need some help making me take the plunge.  Please see below:<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 17, 2015 at 7:15 AM, Ben Coman <span dir="ltr">&lt;<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
&gt; On Wed, Dec 16, 2015 at 1:00 AM, Ben Coman &lt;<a href="mailto:btc@openinworld.com">btc@openinworld.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Dec 16, 2015 at 10:43 AM, Ryan Macnak &lt;<a href="mailto:rmacnak@gmail.com">rmacnak@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
</span><span class="">&gt;&gt; &gt; What would be more helpful is if the VM build was fixed to work with a cross compiler, so it would compile fast enough to test ARM and MIPS on Travis CI alongside IA32 and X64.<br>
&gt;&gt; &gt;<br>
</span><span class="">&gt;&gt; &gt; It would also help if the top-of-tree Intel VMs were always kept working so we&#39;d know which change broke something. Moving the Subversion repository to a more reliable host (which likely means migrating to Git) would also cut down on the false positives Travis reports because the Subversion server has a habit of dropping connections.<br>
&gt;&gt;<br>
&gt;&gt; +1 github :)<br>
<br>
</span>btw, Did you know that github supports subversion clients since 2011 [1]?<br>
Here are supported features [2].  Are these sufficient for your<br>
current svn workflows?<br>
Potentially we could have ONE repository and those liking subversion<br>
can stick with it and those liking git can use that.  Of course, this<br>
would need to be proven.<br></blockquote><div><br></div><div>Ah, that&#39;s interesting.  So my concern is whether github is a safe long-term bet.  Specifically what is there to prevent some third party from buying github, or of github going public and the board taking the decision, or github on its own, deciding to charge for hosting, keeping the data hostage to extract payment?  What safeguards are in place to prevent this?  I&#39;m not interested in &quot;this will never happen&quot; arguments.  I&#39;m interested in hard data please.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[4] Provides pragmatic advice for cutting over.  Esteban appears to<br>
have done similar to step 1 and 2 [3] - but it seem sometimes his<br>
modifications directly update this mirror so its not clear to see when<br>
that branch is an *exact* copy of the current svn trunk.  So I&#39;d love<br>
to see a github repository that is always an *exact* mirror of the svn<br>
repository, with any pharo mods occurring in a branch off that.  Even<br>
better if the repository for svn users resides on github in place of<br>
that mirror.<br>
<br>
I&#39;ve been googling around for problems reported using github via an<br>
svn client, and haven&#39;t found any smoking guns.<br>
Is this something we can trial?  I&#39;m willing to put some effort into<br>
it.  A key requirement would be not interrupting Eliots work on<br>
Spur-64.  Potentially we could stay for months on step 3 [4] with the<br>
CI infrastructure running on the git side, but code check-ins<br>
continuing onthe svn side.<br>
<br>
btw2, [5] provides a use case for the advantages of a full switch.<br>
<br>
cheers -ben<br>
<br>
[1] <a href="https://github.com/blog/966-improved-subversion-client-support" rel="noreferrer" target="_blank">https://github.com/blog/966-improved-subversion-client-support</a><br>
[2] <a href="https://help.github.com/articles/support-for-subversion-clients/" rel="noreferrer" target="_blank">https://help.github.com/articles/support-for-subversion-clients/</a><br>
[3] <a href="https://github.com/pharo-project/pharo-vm/network" rel="noreferrer" target="_blank">https://github.com/pharo-project/pharo-vm/network</a><br>
[4] <a href="http://blogs.atlassian.com/2013/01/atlassian-svn-to-git-migration-technical-side/" rel="noreferrer" target="_blank">http://blogs.atlassian.com/2013/01/atlassian-svn-to-git-migration-technical-side/</a><br>
[5] <a href="http://blogs.atlassian.com/2013/01/svn-to-git-how-atlassian-made-the-switch-without-sacrificing-active-development/" rel="noreferrer" target="_blank">http://blogs.atlassian.com/2013/01/svn-to-git-how-atlassian-made-the-switch-without-sacrificing-active-development/</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div></div>