[Vm-dev] Need an Alien-Core-eem.102 update

[Levente Uzonyi]

Hi Torsten

On Mon, 13 Jan 2020, Torsten Bergmann wrote:

> 
> Hi Eliot,
>
>> there's a simpler solution.  We simply delete Alien-Core-TorstenBergmann.101
>
> Yes - no problem with that and thanks for taking care. But a copy might exist still in local Monticello caches
> on user side.
>
> So an Alien-Core-eem.102 as Dave suggested would nonetheless be the safest addition to compensate
> the Alien-Core-eem.101.mcz (where 101 version was used unfortunately a second time).
>
>> I'll do that by Monday if no one objects. I'm sure Torsten meant no harm and was
>> unaware of the issue.
>
> Yes - for the timestamp I did not notice directly (or even forgot because I guess I just had a newer Pharo
> image on the machine which was already switched git but still includes MCZ tools).
>
> But if you really require the timestamps explicitly on each method for the VMMaker / Alien packages
> then it means one is only allowed to use Squeak or old Pharo versions to contribute / commit and
> VM development will never move away from MCZs in all our lifetime.
>
> The Pharo tools do not have the timestamp in MCZs anymore due to the switch to GIT. Because having the timestamp in the file
> format directly would always mean a change/conflict in the diffs of git anytime - even if there is no real code change
> on the method or class itself.

Can you explain how keeping the timestamps as they are in Monticello would 
introduce change/conflict in git?
Those are just static strings unless you change the method, aren't they?

>
> We all know git is widely accepted in IT shops around the world, really a breeze to work with - now even with and in Smalltalk code.
> With git one gets timestamps out of the box - but also a lot more like proper branching (which is nearly impossible
> to handle in MCZs for the Monticello/Metacello approach). Also GIT can version Smalltalk and non-Smalltalk code
> at the same time and using the same way.
>
> In fact one rarely finds a project which is Smalltalk code only - often you have other assets or code in other languages too.
> And VMMaker is a good example for that.
>
> I personally therefore like git much much more than the old more limiting MCZ solutions. Seen from the outside I still fail to
> understand why
>
>  - on one side the VM code is maintained with git on GitHub
>  - on the other side the core Smalltalk parts like VMMaker are still versioned as MCZ and hosted on old services like
>    SqueakSource / source.squeak.org
>
> Even Squeak might hopefully move forward and use git in the future. Then VMMaker will face the similar issue with the
> timestamps. If I understood sources like
>
>   https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikationen/technische_berichte/tbhpi121.pdf
>
> correctly then one can already use Git as a backend VCS from Squeak too.
>
>> Torsten is a very nice guy.
>
> Thanks for the compliment - but like any other human I have a dark side too :)
>
>> But the issue of no time stamps intr4oduceing lots of noise into Monticello repositories
>> is an annoying g piece of passive aggressive B.S. from the Pharo community which we should push back against.
>
> What kind of noise exactly are you referring too?

When you create an .mcz file with no timestamps in it, all code will 
appear as changed in Monticello. The tool you created the .mcz with is 
therefore broken.

Levente

>
> No need for a conspiracy theory or blaming of the overall Pharo community - loosing the timestamp is related to the
> git switch as explained.
>
> I know there are sometimes personal differences among members of the various communities - and there is potential for
> conflicts depending on personality and if the (code) area of work is the same - and when the ideas for the solution(s) differ.
>
> But basically in all the communities I assume the individuals are trying to move things and ideas forward. Sometimes
> we all pull/push into similar direction - sometimes not because goals or ideas differ slightly or even heavily.
> I assume (and hope) nobody does harmful things willingly just to bug other sides.
>
> Anyhow - I hope 2020 will be a good year with good progress for ALL the communities.
>
> Thx
> T.