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

Sat Apr 23 18:20:21 UTC 2016

Hi Eliot,

RE sqSCCSVersion.h:
I'm not sure if you like this approach, but I decided to just use macros
for version, date and url [1].
I then defined those macros in a global build file [2] and added what I
called $COGVOPTS to CFLAGS [3].
It looks like pharo-vm is doing something similar [4], but their approach
doesn't require as much code to
change. It's probably good if Esteban explains why "he thinks it is not
enough".

Best,
Fabio

[1]
https://github.com/fniephaus/squeak/blob/Cog/platforms/Cross/vm/sqSCCSVersion.h#L68-L86
[2] https://github.com/fniephaus/squeak/blob/Cog/.travis_build.sh#L8-L11
[3]
https://github.com/fniephaus/squeak/blob/ae1a8fd6f99d0e03c37d4037c1586870ca6ff3a0/build.macos32x86/common/Makefile.vm#L107
[4]
https://github.com/pharo-project/pharo-vm/blob/09a717119732559b43a13e8c6f5c43a16bba18a3/scripts/extract-commit-info.sh

-- 

On Sat, Apr 23, 2016 at 7:55 PM Tobias Pape <Das.Linux at gmx.de> wrote:

>
>
> On 23.04.2016, at 19:44, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> >
> > Hi Tobias,
> >
> >> On Apr 23, 2016, at 10:30 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >>
> >>
> >>
> >>> On 23.04.2016, at 19:21, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >>>
> >>> Hi Fabio,
> >>>
> >>>  and the "if not, why not?" question is a request for information, not
> an expression of annoyance. Subversion tags update the source in checkin.
> I remember Igor saying that he couldn't find out how to make gig do the
> same with version numbers (forgive me if my recollection is incorrect).
> But if git doesn't support this then we need to invent some scheme that
> does work, for example doing two commits, one to generate a hash and
> another to commit a tag.  But we need sensible increment isn't version
> numbers, not stupid hashes.  It has to be a requirement that one can tell
> from the output of
> >>>   myvm -version
> >>>   yourvm -version
> >>> whether the VMs are built from the same or different versions of the
> source and which one is more up-to-date, and that this depends on version
> number, not irrelevancies such as build date.
> >>
> >> I did such stuff like 4 years ago for self (don't ask why)
> >> I changed their whole VM build process to CMake.
> >>
> >> Here's some parts that vaguely do what you want want:
> >>
> >> This uses "date" to generate a vm build date (lines 12 and following)
> >> and "git" to extract VCS infos (lines 39 and following)
> >>
> https://github.com/russellallen/self/blob/master/vm/cmake/configureVmDate.cmake.in
> >> (it is namend .in because it gets configured itself from elsewhere)
> >>
> >> It is clearly possible to switch all the stuff to git and cmake and I'd
> like to see that happen.
> >> I would love to have time for that (although it regularly makes me
> angry :D).
> >>
> >> Best regards
> >>   -Tobias
> >>
> >> PS: Personally (i.e. IMHO), I think that IF we go with cmake, we should
> follo Ians way with
> >>   probably some mix of the self vm stuff. It can really work. And it
> can also help us
> >>   getting things compiled on MS compilers, btw.
> >
> > What do you mean by "Ian's way" exactly?  Please describe it.
> >
> > Things I know:
> > - Ian's autoconf code (platforms/unix/conf, the various additional
> snippets that get included when one builds the autoconf support, rather
> than things that get computed at build time) is extremely difficult to work
> with
>
> Ian's unix conf uses CMake for a while now.
> There's no autoconf.
> Thers no platforms/unix/conf, neither in
>         http://www.squeakvm.org/svn/squeak/trunk/platforms/unix/
> nor in
>         https://github.com/fniephaus/squeak/tree/master/platforms/unix
>
>
> So I'm a bit confused about what you refer to.
>
> > - gmake files work with MS compilers too
> >
> > I am strongly in favor of gmake files.  It's /much/ easier to work with.
>
> Sorry, i beg to differ.
>
> >  Please, please, please let's limit the use of cmake to generating a
> config file as I've already discussed.
>
> you mean gnu make?
>
>         :/
>
> However, its saturday evening, I don't like to argue at that time.
> Maybe I'll find some time next week to make a write up :)
>
> Best
>         -Tobias
>
>
> >
> >>
> >>
> >>>
> >>> _,,,^..^,,,_ (phone)
> >>>
> >>>> On Apr 23, 2016, at 9:54 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >>>>
> >>>> 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:
> >>>>>
> >>>>> 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/4b8d6338/attachment.htm