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

Thu Jun 16 16:56:56 UTC 2016

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/