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

Fabio Niephaus lists at fniephaus.com
Sat Apr 23 16:40:14 UTC 2016


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. 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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160423/78f92e91/attachment.htm


More information about the Vm-dev mailing list