On Mon, Jul 3, 2017 at 2:00 PM, <estebanlm@gmail.com> wrote:

Hello!

This is my weekly ChangeLog, from 26 June 2017 to 2 July 2017.
You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=26/6/2017&to=2/7/2017

ChangeLog
=========

29 June 2017:
-------------

*�� ... and I spent some time figuring out why windows users have a persistent error about access files.

�� We should always remember the windows path limitations (256) :)

�� Now, the workaround for this is to execute this in command line:

�� ----
�� git config --system core.longpaths true
�� ----

�� but of course, this is just a workaround because people using Iceberg could not hava installed a
�� command line git client. I will need to check in the future this :(

Nice pickup.�� I notice this command creates the file /etc/gitconfig like this...

�� [core]

�� longpaths = true

and instead using --local update

$ cp .git/config /tmp/oldconfig

$ git config --local core.longpaths true

$ diff .git/config /tmp/oldconfig

6d5

< �� longpaths = true

Sorry I don't have time to test further, but if --local has the same positive effect per repo as --global,

could Pharo modify the config text file directly?

��

*�� I spent some time trying to get [Iceberg version dev-0.5](https://github.com/pharo-vcs/iceberg/tree/dev-0.5)
�� to load properly (yesterday's script is not working).

�� The reason is that +Metacello+ fails to upgrade packages from a baseline. And there is no way (at least
�� that I found) to force the upload.

�� So this is the updated script to test dev-0.5:

�� 1. Download latest vm and image.

�� ----
�� wget -O- get.pharo.org/64/70+vmLatest | bash
�� wget -O- get.pharo.org/64/70+vmTLatest | bash # for linux systems
�� ----

�� 2. Execute this on your image

�� ----
�� #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration' 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg'
�� 'LibGit-Core' 'BaselineOfLibGit')
�� do: [ :each | each asPackage removeFromSystem ].

�� Metacello new
�� baseline: 'Iceberg';
�� repository: 'github://pharo-vcs/iceberg:dev-0.5';
�� load.
�� ----

�� This should actually remove old iceberg version then install new one.

28 June 2017:
-------------

*�� Ok, I get the VM to compile correctly with the new libgit2 version, and now +latest vm+ comes with
�� +libgit 0.25.1+ for both 32 and 64 bits versions.

�� I also made some minor fixes to +iceberg dev-0.5+ and it should be ready to test and release. This
�� version incorporates some important changes that will allow us to work with it to make changes to
�� Pharo itself (and that will be noticed on big projects):

�� * it has cherry-pick.
�� * it speeds up sincronization by introducing more precise comparisons instead making a "full scan"

sincronization = something naughty you do at regular intervals ?? �� %^)

��

�� * it keeps in sync branch on disk and branch on iceberg (before it was keeping them separately and it was very confusing)

�� To test it, you can execute:

�� ----
�� wget -O- get.files.org/64/70+vmLatest | bash
�� wget -O- get.files.org/64/70+vmTLatest | bash # on linux systems
�� ----

�� then you will need to load version +dev-0.5+ :

�� ----
�� Metacello new
�� baseline: 'Iceberg';
�� repository: 'github://pharo-vcs/iceberg:dev-0.5';
�� load.
�� "And you will need to execute this... I will need to update the baseline with this,
�� now that I think :)"
�� LGitExternalStructure allSubclassesDo: #compileFields.
�� ----

*�� I finished ensuring [iceberg](https://github.com/pharo-vcs/iceberg/tree/dev-0.5) will work on 64 bits.

�� Now, I needed to make some fixes for UFFI, which I put in [case: 20198](https://pharo.fogbugz.com/f/cases/20198) (it is imperative to include
�� this to be able to backport 0.5 into Pharo 6.0). Also, I will need to promote a new VM as stable.

�� I'm not sure I want to backport this into Pharo 6. I know I promised but complications are... more than
�� benefits, I think: You will need a new VM. People will not know that and they will download a P6 image
�� with the older VM and this will cause problems.

�� Maybe is better to move all this to P7?

cheers!
Esteban