[Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC

Fri Jun 17 16:52:02 UTC 2016

Hi John,

-- 

On Thu, Jun 16, 2016 at 7:50 PM John McIntosh <
johnmci at smalltalkconsulting.com> wrote:

>
>
>  OS X 64-bit
>
> Sista fails
>
>
> Need some pointers so I can debug this
>

Here's the failing build:
https://travis-ci.org/OpenSmalltalk/vm/jobs/138342179#L73

According to [1], there is supposed to be a [2]. There isn't, but there is
a [3]. So I'm assuming that 64bit spursista has not been implemented yet
(same with Linux 64bit).
I will disable OS X 64-bit Spur Sista builds for now.

[1]
https://github.com/OpenSmalltalk/vm/blob/56c4157d4a41fbc6d8f98e241c4eec954d15ebd2/build.macos64x64/squeak.sista.spur/Makefile#L6
[2] https://github.com/OpenSmalltalk/vm/tree/Cog/spursista64src/vm
[3] https://github.com/OpenSmalltalk/vm/tree/Cog/spursistasrc/vm

>
>
>
> Sent from my iPhone
>
> On Jun 16, 2016, at 9:56 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>
> Hi All,
>
> On Jun 16, 2016, at 9:38 AM, Ben Coman <btc at openinworld.com> wrote:
>
>
>
> On Thu, Jun 16, 2016 at 5:10 PM, Serge Stinckwich
>
> <serge.stinckwich at gmail.com> wrote:
>
>
> On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff
>
> <timfelgentreff at gmail.com> wrote:
>
> Hi all,
>
>
> Very impressive work, Tim&Fabio ! The power of full-automation !
>
>
> as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was
>
> migrated to GitHub. Automatic builds are running
>
> (https://ci.appveyor.com/project/timfel/vm/branch/Cog,
>
> https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded
>
> (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files).
>
>
> About uploading binary artifacts, this is something I asked and this
>
> nice that Fabio make it work :-)
>
>
> What is the advantage of this?   The 44 .image files stored in the
>
> repository take up 196MB, doubling the space.
>
>
> What are the images?  IIRC there are no images in the svn repo. The only
> big files are sources files for  various key squeak and Pharo releases.
> Did I check in images in the images directory by mistake?  There should be
> nine there; they're to be downloaded and built/converted, not checked into
> the repository.
>
> So please, list these image files here...
>
> I guess thats not a
>
> big deal for a one time cost to clone the repository - for most of us
>
> with wide bandwidths in the modern world.  But some places still have
>
> limited bandwidth.
>
>
> Also SSD are sometimes not so big, and maybe someone wants to compile
>
> on a smaller system like as RasPi (although it can handle reasonable
>
> sized storage cards.)
>
>
> Apparently there is some problems with some artifacts that have a
>
> double .zip extension.
>
>
> Right now we have enabled all platform, object memory and bytecode set
>
> combinations that I found build scripts for - most work, but OS X 64-bit
>
> Sista is failing right now (32-bit works). At some point we'll have to
>
> decide which combinations to put into the CI config as "allowed failures"
> to
>
> get a green badge :)
>
>
> Another thing for those not familiar with Git: Right now the entire
>
> repository is 360MB, including all history. Most of that is old images that
>
> were at one point committed to SVN and that have been pulled into the
>
> repository. We could clean those out (removing them from the history) to
>
> make the repository smaller, but I felt ~400MB is still ok (albeit
>
> technically over the Github quota. We'll see of they complain). I would
> like
>
> to ask everyone to stop committing large binary files into the repository,
>
> however. Git is simply not very suited to dealing with binaries.
>
> If there is a need for that, Github has support for git-lfs, which offers
> 1GB of free
>
> storage with a 1GB bandwith limit per month.
>
>
> Initially I said... "Please, can we consider doing that.  1GB/1GB
>
> seems ample, and $5/mth provides 50GB/50GB [1] (and you'd expect those
>
> quotas to expand over time.) And a quick reference to how it works
>
> [2]. However enabling lfs doesn't automatically convert existing
>
> commits.  The recommend migration tool seems to be git-lfs-migrate
>
> [3].  But history is rewritten, so any clones will need to be rebased
>
> - so now at the start is probably the best time to do it !  "
>
>
> But then I read lfs currently doesn't work properly with forked repos [4]
> [5]
>
> Also early lfs versions seem to have had a performance issue [6],
>
> but that may be recently solved [7].
>
>
>
> btw, is anyone going to be using git-svn, or is everyone making the
>
> big jump pure git?
>
>
> In any case, I'm very glad to see the repo on git.  Thanks all that
>
> helped make it happen, and Tim & Fabio for the work.
>
>
> cheers -ben
>
>
> [1]
> https://help.github.com/articles/billing-plans-for-git-large-file-storage/
>
> [2] https://git-lfs.github.com/
>
> [3] https://github.com/bozaro/git-lfs-migrate
>
> [4]
> https://medium.com/@megastep/github-s-large-file-storage-is-no-panacea-for-open-source-quite-the-opposite-12c0e16a9a91#.omrd0qw6n
>
> [5] https://github.com/github/git-lfs/issues/773
>
> [6]
> https://www.bountysource.com/issues/21357625-git-lfs-is-unusable-slow-especially-on-windows
>
> [7] https://developer.atlassian.com/blog/2016/04/git-lfs-12-clone-faster/
>
>
>
>
>
>
> If we need more, we can look at
>
> the different billing levels.
>
>
> If you're familiar with Git, the only new thing to watch out for is the
>
> updateSCSSVersions script as described in the README. It's not relevant for
>
> the CI, but your own binaries will only show correct versions if this
> script
>
> runs at appropriate times.
>
>
> If you are not familiar with Git and don't care, there are scripts for
>
> committing that should take care of everything as described in the README.
>
> Again, let us know if anything doesn't work. The only difference vs SVN to
>
> watch out for for you will be that the old scripts/svnci would commit your
>
> changes to the server, whereas the scripts/gitci script only commits them
>
> locally. You'll have to run `git pull` and `git push` to get them up to the
>
> server.
>
>
> If you have any questions regarding the repository setup please don't
>
> hesitate to ask. You shouldn't be able to break anything, since we've
>
> disabled force pushes to both master and Cog (and thus any chance of
>
> destroying history).
>
>
> What is favorite way of contributing for people outside the vm team ?
>
> pull-requests ?
>
>
> Regards,
>
> --
>
> Serge Stinckwich
>
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>
> Every DSL ends up being Smalltalk
>
> http://www.doesnotunderstand.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160617/39c65bd4/attachment-0001.htm