<div dir="ltr">Hi all,<div><br></div><div>Bert already mentioned that I've been working on migrating the repository from SVN to Git.</div><div>I believe there are three problems that need to be solved here:</div><div><br></div><div><b>1. Migrating SVN externals for sharing code between branches</b></div><div>This is currently used to share a few directories (e.g. platforms/Cross/plugins) across different</div><div><span style="line-height:1.5">branches. But Git does no support this kind of code sharing. Instead, it supports submodules [1]</span></div><div><span style="line-height:1.5">and subtrees </span><span style="line-height:1.5">[2]. I would suggest to move code that we want to share into separate Git</span></div><div><span style="line-height:1.5">repositories and include them as submodules. I think submodules are easier to </span><span style="line-height:1.5">understand</span></div><div><span style="line-height:1.5">(GitHub integrates them nicely in their UI). The only drawback: if someone updates </span><span style="line-height:1.5">code </span><span style="line-height:1.5">in a</span></div><div><span style="line-height:1.5">shared repository, one needs to update all references to this repository as well. But I'd </span><span style="line-height:1.5">say this</span></div><div><span style="line-height:1.5">is also a good thing: if someone changes e.g. a plugin and the change is compatible to </span><span style="line-height:1.5">Cog,</span></div><div><span style="line-height:1.5">but incompatible to the interpreter vm, then the interpreter branch is not automatically </span><span style="line-height:1.5">broken</span></div><div><span style="line-height:1.5">as soon as one pushes the plugin change. If the above is unclear, I'm happy to explain</span></div><div><span style="line-height:1.5">submodules in more detail.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5"><b>2. Versioning and new releases</b></span></div><div><span style="line-height:1.5">If we migrate to Git, I'd recommend to deprecate the way we do versioning in SVN. Instead, we</span></div><div><span style="line-height:1.5">should use Git commit hashes and Git tags. Let's say we want to release a new version, we tag</span></div><div><span style="line-height:1.5">the commit of interest with e.g. v1.0.0. When building the Cog VM on this tag, the version will be</span></div><div><span style="line-height:1.5">v1.0.0. </span><span style="line-height:1.5">If we use GitHub, we might as well use a CI service such as Travis CI [3] to automate the</span></div><div><span style="line-height:1.5">build process. That means, each time someone pushes changes to GitHub, Travis CI will build a</span></div><div><span style="line-height:1.5">new Cog VM (we can call this "bleeding edge"). Let's say I push changes right after the release</span></div><div><span style="line-height:1.5">of v1.0.0, the version for the next build will be something like v1.0.0-</span>37553a9 with "37553a9"</div><div>being the short SHA1 identifying my latest commit. If we want to release e.g. v1.1.0, we just tag</div><div>a newer commit and GitHub/Travis CI does the rest for us. I already have this working, you can</div><div>find a Travis build at [4] and the result at [5]. Obviously, we can push the binaries to a different</div><div>server.</div><div><br></div><div><b>3. Keeping a copy of the code</b></div><div>We of course want to keep a copy of our code at all times in case something happens with</div><div>GitHub. There are already tools that we can use to automate this. However, I wouldn't try to keep</div><div>the old SVN repository in sync. I believe this might be quite difficult and I don't see a reason to</div><div>maintain something we want to deprecate in the first place. <span style="line-height:1.5">Anyway, it should be fairly easy to</span></div><div>set up a tool that creates a backup on one of our servers whenever we change code on GitHub.</div><div><br></div><div><br></div><div>Doing a migration from SVN to Git(Hub) takes a few hours and I'd recommend we stop pushing</div><div>code to the SVN as soon as we start to migrate. This obviously requires everyone working <span style="line-height:1.5">with</span></div><div><span style="line-height:1.5">the code base to switch to Git. So please let me know if everyone is comfortable with the</span></div><div>migration. If we want to do this next week, I'd recommend to do it on a Thursday or a Friday,</div><div>because I would be able to do it with Bert sitting two rooms next to me :)</div><div><br></div><div>I hope I have thought about the important things and I'm happy to answer any questions you</div><div>might have.</div><div><br></div><div>Best,</div><div>Fabio</div><div><br></div><div>[1] <a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules" target="_blank">https://git-scm.com/book/en/v2/Git-Tools-Submodules</a></div><div>[2] <a href="http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/" target="_blank">http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/</a></div><div>[3] <a href="http://travis-ci.org">http://travis-ci.org</a></div><div>[4] <a href="https://travis-ci.org/fniephaus/squeak/builds/119507180">https://travis-ci.org/fniephaus/squeak/builds/119507180</a></div><div>[5] <a href="https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/cog/v0.1.0/">https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/cog/v0.1.0/</a></div><div><br></div><div><br></div><div></div><div dir="ltr"><div><br><div>-- <br></div></div></div><div dir="ltr"><div><br><div class="gmail_quote"><div dir="ltr">On Sat, Apr 23, 2016 at 5:10 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Sat, Apr 23, 2016 at 02:22:29PM +0200, Nicolas Cellier wrote:<br>
><br>
> 2016-04-23 13:56 GMT+02:00 Cl??ment Bera <<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>>:<br>
><br>
> ><br>
> > On Sat, Apr 23, 2016 at 12:54 PM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>><br>
> > wrote:<br>
> ><br>
> >><br>
> >> Actually, Fabio did a complete migration while <a href="http://squeakvm.org" rel="noreferrer" target="_blank">squeakvm.org</a> was out.<br>
> >> This had a full history of all SVN commits.<br>
> >><br>
> >> ???Unfortunately??? Ian fixed the server too soon so development continued on<br>
> >> SVN, so now the git repo is again out-of-date.<br>
> >><br>
> >> We would need to freeze the SVN, do the migration again, and use git from<br>
> >> that point on. It would involve a day of downtime, but doing this sooner<br>
> >> than later would be a good thing.<br>
> >><br>
> >><br>
> doesn't gitsvn help?<br>
><br>
<br>
I have to admit that I did not even know that an active git svn bridge<br>
was possible. It sounds like this it might be very helpful.<br>
<br>
It would be great to have the advantages of git for development, and<br>
it could also be helpful to be able to have the <a href="http://squeakvm.org" rel="noreferrer" target="_blank">squeakvm.org</a> repo updated<br>
periodically from git. There are portions of the platforms tree that Eliot<br>
has been able to make identical for oscog and trunk, and this seems like<br>
a worthwhile effort to continue.<br>
<br>
Another possible advantage is that Ian's cmake build process takes advantage<br>
of the SVN revision numbering, and it would be good to make sure this stays<br>
healthy as development proceeds (it's a lot nicer than autotools).<br>
<br>
Eliot, do you have a view on this?<br>
<br>
Dave<br>
<br>
</blockquote></div></div></div></div>