<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi,</div><div class=""><br class=""></div>I would like to have a list of constraints so we can sort it (otherwise this will never happen… :S)<div class="">So far I have: </div><div class=""><br class=""></div><div class="">- sqSCCSVersion.h adapt to git. In Pharo we already have something but I do not think is enough… I will take a look to this. </div><div class="">- do not break Cadence builds. AFAIK, nothing forbids jenkins to stop using SVN and start using GIT (we also use Jenkins for our builds and we didn’t found any problem)… someone has to do the change, but it should be fairly straightforward. Who is the person who can take this task? (I’d do it, but I suppose Cadence has access policy to that)</div><div class=""><br class=""></div><div class="">what more?</div><div class=""><br class=""></div><div class="">(please, take into account that this is very important for us, and that I personally will be in a better position to go back to the trunk, and then contribute back my changes, that’s why I’m pushing it)</div><div class=""><br class=""></div><div class="">Esteban</div><div class=""><br class=""></div><div class="">ps: As far as I understood, Fabio didn’t said “next thursday”, but “one thursday” :)</div><div class=""><br class=""></div><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Apr 2016, at 18:54, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" class="">eliot.miranda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Hi Fabio,<br class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">On Apr 23, 2016, at 9:40 AM, Fabio Niephaus <<a href="mailto:lists@fniephaus.com" class="">lists@fniephaus.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><span class=""></span></div></blockquote><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">Bert already mentioned that I've been working on migrating the repository from SVN to Git.</div><div class="">I believe there are three problems that need to be solved here:</div><div class=""><br class=""></div><div class=""><b class="">1. Migrating SVN externals for sharing code between branches</b></div><div class="">This is currently used to share a few directories (e.g. platforms/Cross/plugins) across different</div><div class=""><span style="line-height: 1.5;" class="">branches. But Git does no support this kind of code sharing. Instead, it supports submodules [1]</span></div><div class=""><span style="line-height: 1.5;" class="">and subtrees </span><span style="line-height: 1.5;" class="">[2]. I would suggest to move code that we want to share into separate Git</span></div><div class=""><span style="line-height: 1.5;" class="">repositories and include them as submodules. I think submodules are easier to </span><span style="line-height: 1.5;" class="">understand</span></div><div class=""><span style="line-height: 1.5;" class="">(GitHub integrates them nicely in their UI). The only drawback: if someone updates </span><span style="line-height: 1.5;" class="">code </span><span style="line-height: 1.5;" class="">in a</span></div><div class=""><span style="line-height: 1.5;" class="">shared repository, one needs to update all references to this repository as well. But I'd </span><span style="line-height: 1.5;" class="">say this</span></div><div class=""><span style="line-height: 1.5;" class="">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;" class="">Cog,</span></div><div class=""><span style="line-height: 1.5;" class="">but incompatible to the interpreter vm, then the interpreter branch is not automatically </span><span style="line-height: 1.5;" class="">broken</span></div><div class=""><span style="line-height: 1.5;" class="">as soon as one pushes the plugin change. If the above is unclear, I'm happy to explain</span></div><div class=""><span style="line-height: 1.5;" class="">submodules in more detail.</span></div><div class=""><span style="line-height: 1.5;" class=""><br class=""></span></div><div class=""><span style="line-height: 1.5;" class=""><b class="">2. Versioning and new releases</b></span></div><div class=""><span style="line-height: 1.5;" class="">If we migrate to Git, I'd recommend to deprecate the way we do versioning in SVN. Instead, we</span></div><div class=""><span style="line-height: 1.5;" class="">should use Git commit hashes and Git tags.<span class="Apple-converted-space"> </span></span></div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">But have you modified platforms/Cross/vm/sqSCCSVersion.h to capture this information? If so, can you please send me the code so I can integrate it? If not, why not?</span><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><span style="line-height: 1.5;" class="">Let's say we want to release a new version, we tag</span></div><div class=""><span style="line-height: 1.5;" class="">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 class=""><span style="line-height: 1.5;" class="">v1.0.0. </span><span style="line-height: 1.5;" class="">If we use GitHub, we might as well use a CI service such as Travis CI [3] to automate the</span></div><div class=""><span style="line-height: 1.5;" class="">build process. That means, each time someone pushes changes to GitHub, Travis CI will build a</span></div><div class=""><span style="line-height: 1.5;" class="">new Cog VM (we can call this "bleeding edge"). Let's say I push changes right after the release</span></div><div class=""><span style="line-height: 1.5;" class="">of v1.0.0, the version for the next build will be something like v1.0.0-</span>37553a9 with "37553a9"</div><div class="">being the short SHA1 identifying my latest commit. If we want to release e.g. v1.1.0, we just tag</div><div class="">a newer commit and GitHub/Travis CI does the rest for us. I already have this working, you can</div><div class="">find a Travis build at [4] and the result at [5]. Obviously, we can push the binaries to a different</div><div class="">server.</div><div class=""><br class=""></div><div class=""><b class="">3. Keeping a copy of the code</b></div><div class="">We of course want to keep a copy of our code at all times in case something happens with</div><div class="">GitHub. There are already tools that we can use to automate this. However, I wouldn't try to keep</div><div class="">the old SVN repository in sync. I believe this might be quite difficult and I don't see a reason to</div><div class="">maintain something we want to deprecate in the first place. <span style="line-height: 1.5;" class="">Anyway, it should be fairly easy to</span></div><div class="">set up a tool that creates a backup on one of our servers whenever we change code on GitHub.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Doing a migration from SVN to Git(Hub) takes a few hours and I'd recommend we stop pushing</div><div class="">code to the SVN as soon as we start to migrate. This obviously requires everyone working <span style="line-height: 1.5;" class="">with</span></div><div class=""><span style="line-height: 1.5;" class="">the code base to switch to Git. So please let me know if everyone is comfortable with the</span></div><div class="">migration. If we want to do this next week, I'd recommend to do it on a Thursday or a Friday,</div><div class="">because I would be able to do it with Bert sitting two rooms next to me :)</div></div></div></blockquote><div class=""><br class=""></div>I'm not happy to migrate until there's a functional subversion bridge that works and doesn't break my builds. Cadence pays for my time (and hence pays for a lot of the VM development we enjoy) and its builds use Jenkins and subversion and I will not cooperate with any effort that sabotages this. "Next Thursday" doesn't appear to appreciate the constraints. This has to be done carefully or I will not cooperate.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I hope I have thought about the important things and I'm happy to answer any questions you</div><div class="">might have.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Fabio</div><div class=""><br class=""></div><div class="">[1] <a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules" target="_blank" class="">https://git-scm.com/book/en/v2/Git-Tools-Submodules</a></div><div class="">[2] <a href="http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/" target="_blank" class="">http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/</a></div><div class="">[3]<span class="Apple-converted-space"> </span><a href="http://travis-ci.org/" class="">http://travis-ci.org</a></div><div class="">[4] <a href="https://travis-ci.org/fniephaus/squeak/builds/119507180" class="">https://travis-ci.org/fniephaus/squeak/builds/119507180</a></div><div class="">[5] <a href="https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/cog/v0.1.0/" class="">https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/cog/v0.1.0/</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""></div><div dir="ltr" class=""><div class=""><br class=""><div class="">--<span class="Apple-converted-space"> </span><br class=""></div></div></div><div dir="ltr" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sat, Apr 23, 2016 at 5:10 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank" class="">lewis@mail.msen.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><br class="">On Sat, Apr 23, 2016 at 02:22:29PM +0200, Nicolas Cellier wrote:<br class="">><br class="">> 2016-04-23 13:56 GMT+02:00 Cl??ment Bera <<a href="mailto:bera.clement@gmail.com" target="_blank" class="">bera.clement@gmail.com</a>>:<br class="">><br class="">> ><br class="">> > On Sat, Apr 23, 2016 at 12:54 PM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de" target="_blank" class="">bert@freudenbergs.de</a>><br class="">> > wrote:<br class="">> ><br class="">> >><br class="">> >> Actually, Fabio did a complete migration while<span class="Apple-converted-space"> </span><a href="http://squeakvm.org/" rel="noreferrer" target="_blank" class="">squeakvm.org</a><span class="Apple-converted-space"> </span>was out.<br class="">> >> This had a full history of all SVN commits.<br class="">> >><br class="">> >> ???Unfortunately??? Ian fixed the server too soon so development continued on<br class="">> >> SVN, so now the git repo is again out-of-date.<br class="">> >><br class="">> >> We would need to freeze the SVN, do the migration again, and use git from<br class="">> >> that point on. It would involve a day of downtime, but doing this sooner<br class="">> >> than later would be a good thing.<br class="">> >><br class="">> >><br class="">> doesn't gitsvn help?<br class="">><br class=""><br class="">I have to admit that I did not even know that an active git svn bridge<br class="">was possible. It sounds like this it might be very helpful.<br class=""><br class="">It would be great to have the advantages of git for development, and<br class="">it could also be helpful to be able to have the<span class="Apple-converted-space"> </span><a href="http://squeakvm.org/" rel="noreferrer" target="_blank" class="">squeakvm.org</a><span class="Apple-converted-space"> </span>repo updated<br class="">periodically from git. There are portions of the platforms tree that Eliot<br class="">has been able to make identical for oscog and trunk, and this seems like<br class="">a worthwhile effort to continue.<br class=""><br class="">Another possible advantage is that Ian's cmake build process takes advantage<br class="">of the SVN revision numbering, and it would be good to make sure this stays<br class="">healthy as development proceeds (it's a lot nicer than autotools).<br class=""><br class="">Eliot, do you have a view on this?<br class=""><br class="">Dave<br class=""><br class=""></blockquote></div></div></div></div></div></blockquote><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class="">_,,,^..^,,,_ (phone)</span></div></div></div></blockquote></div><br class=""></div></div></body></html>