On Mon, Jul 3, 2017 at 2:00 PM, <esteba...@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
>
>
