[Vm-dev] svn git bridge? (was: Spur corrupts large images when saving)

Sat Apr 23 16:54:22 UTC 2016

Hi Fabio,

> On Apr 23, 2016, at 9:40 AM, Fabio Niephaus <lists at fniephaus.com> wrote:
> 
> Hi all,
> 
> Bert already mentioned that I've been working on migrating the repository from SVN to Git.
> I believe there are three problems that need to be solved here:
> 
> 1. Migrating SVN externals for sharing code between branches
> This is currently used to share a few directories (e.g. platforms/Cross/plugins) across different
> branches. But Git does no support this kind of code sharing. Instead, it supports submodules [1]
> and subtrees [2]. I would suggest to move code that we want to share into separate Git
> repositories and include them as submodules. I think submodules are easier to understand
> (GitHub integrates them nicely in their UI). The only drawback: if someone updates code in a
> shared repository, one needs to update all references to this repository as well. But I'd say this
> is also a good thing: if someone changes e.g. a plugin and the change is compatible to Cog,
> but incompatible to the interpreter vm, then the interpreter branch is not automatically broken
> as soon as one pushes the plugin change. If the above is unclear, I'm happy to explain
> submodules in more detail.
> 
> 2. Versioning and new releases
> If we migrate to Git, I'd recommend to deprecate the way we do versioning in SVN. Instead, we
> should use Git commit hashes and Git tags.

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?

> Let's say we want to release a new version, we tag
> the commit of interest with e.g. v1.0.0. When building the Cog VM on this tag, the version will be
> v1.0.0. If we use GitHub, we might as well use a CI service such as Travis CI [3] to automate the
> build process. That means, each time someone pushes changes to GitHub, Travis CI will build a
> new Cog VM (we can call this "bleeding edge"). Let's say I push changes right after the release
> of v1.0.0, the version for the next build will be something like v1.0.0-37553a9 with "37553a9"
> being the short SHA1 identifying my latest commit. If we want to release e.g. v1.1.0, we just tag
> a newer commit and GitHub/Travis CI does the rest for us. I already have this working, you can
> find a Travis build at [4] and the result at [5]. Obviously, we can push the binaries to a different
> server.
> 
> 3. Keeping a copy of the code
> We of course want to keep a copy of our code at all times in case something happens with
> GitHub. There are already tools that we can use to automate this. However, I wouldn't try to keep
> the old SVN repository in sync. I believe this might be quite difficult and I don't see a reason to
> maintain something we want to deprecate in the first place. Anyway, it should be fairly easy to
> set up a tool that creates a backup on one of our servers whenever we change code on GitHub.
> 
> 
> Doing a migration from SVN to Git(Hub) takes a few hours and I'd recommend we stop pushing
> code to the SVN as soon as we start to migrate. This obviously requires everyone working with
> the code base to switch to Git. So please let me know if everyone is comfortable with the
> migration. If we want to do this next week, I'd recommend to do it on a Thursday or a Friday,
> because I would be able to do it with Bert sitting two rooms next to me :)

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.

> 
> I hope I have thought about the important things and I'm happy to answer any questions you
> might have.
> 
> Best,
> Fabio
> 
> [1] https://git-scm.com/book/en/v2/Git-Tools-Submodules
> [2] http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
> [3] http://travis-ci.org
> [4] https://travis-ci.org/fniephaus/squeak/builds/119507180
> [5] https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/cog/v0.1.0/
> 
> 
> 
> -- 
> 
>> On Sat, Apr 23, 2016 at 5:10 PM David T. Lewis <lewis at mail.msen.com> wrote:
>> 
>> On Sat, Apr 23, 2016 at 02:22:29PM +0200, Nicolas Cellier wrote:
>> >
>> > 2016-04-23 13:56 GMT+02:00 Cl??ment Bera <bera.clement at gmail.com>:
>> >
>> > >
>> > > On Sat, Apr 23, 2016 at 12:54 PM, Bert Freudenberg <bert at freudenbergs.de>
>> > > wrote:
>> > >
>> > >>
>> > >> Actually, Fabio did a complete migration while squeakvm.org was out.
>> > >> This had a full history of all SVN commits.
>> > >>
>> > >> ???Unfortunately??? Ian fixed the server too soon so development continued on
>> > >> SVN, so now the git repo is again out-of-date.
>> > >>
>> > >> We would need to freeze the SVN, do the migration again, and use git from
>> > >> that point on. It would involve a day of downtime, but doing this sooner
>> > >> than later would be a good thing.
>> > >>
>> > >>
>> > doesn't gitsvn help?
>> >
>> 
>> I have to admit that I did not even know that an active git svn bridge
>> was possible. It sounds like this it might be very helpful.
>> 
>> It would be great to have the advantages of git for development, and
>> it could also be helpful to be able to have the squeakvm.org repo updated
>> periodically from git. There are portions of the platforms tree that Eliot
>> has been able to make identical for oscog and trunk, and this seems like
>> a worthwhile effort to continue.
>> 
>> Another possible advantage is that Ian's cmake build process takes advantage
>> of the SVN revision numbering, and it would be good to make sure this stays
>> healthy as development proceeds (it's a lot nicer than autotools).
>> 
>> Eliot, do you have a view on this?
>> 
>> Dave

_,,,^..^,,,_ (phone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160423/43d7355e/attachment.htm