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

Ben Coman btc at openinworld.com
Tue Jan 14 17:22:50 UTC 2020


On Wed, 15 Jan 2020 at 01:18, Ben Coman <btc at openinworld.com> wrote:
>
>
>
> On Tue, 14 Jan 2020 at 20:55, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>>
>>
>> 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?
>
>
> To simplify things with an analogous example, lets put aside Tonel and Metacello
> and consider git's treatment of metadata in a basic file-out.
>
> # SETUP TEST REPO
>
> $ mkdir test & cd test
> $ git init
> $ git config --global user.name "Test"
> $ git config --global user.email "test at test.com"
> $ cat > some.st <<EOF
> Object subclass: #MyClass
>         instanceVariableNames: ''
>         classVariableNames: ''
>         poolDictionaries: ''
>         category: 'Example'!
>
> !MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'!
> method1
>         self inform: 'line 1 branch master'.
>         self inform: 'line 2 branch master'.
>         self inform: 'line 3 branch master'.
>         self inform: 'line 4 branch master'.
> ! !
> EOF
>
> $ git add some.st
> $ git commit -m "First commit"
> $ git branch b1
> $ git branch b2
> $ git branch b3
> $ git branch b4
>
> # FIRST EXPERIMENT, BASELINE AN UPDATE & MERGE WITHOUT TIMESTAMPS
>
> $ git checkout b1
> $ vi some.st
>     - self inform: 'line 1 branch master'.
>     + self inform: 'line 1 branch b1'.
> $ git commit -am "line 1 branch b1"
>
> $ git checkout b2
> $ vi some.st
>     - self inform: 'line 1 branch master'.
>     + self inform: 'line 1 branch b3'.
> $ git commit -am "line 1 branch b3"

# CORRECTION, of course the moment I hit send I notice a copy-paste
error. Obviously it should be...
$ git checkout b2
$ vi some.st
     - self inform: 'line 3 branch master'.
     + self inform: 'line 3 branch b2'.
$ git commit -am "line 3 branch b2"

> $ git diff b1
> $ git merge b1
> $ cat some.st
>      ==> merged worked fine, no conflicts
>
> # SECOND EXPERIMENT, UPDATE & MERGE WITH TIMESTAMPS
>
> $ git checkout b3
> $ vi some.st
>     -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'!
>     +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:10'!
>     - self inform: 'line 1 branch master'.
>     + self inform: 'line 1 branch b3'.
> $ git commit -am "line 1 branch b3"
>
> $ git checkout b4
> $ vi some.st
>     -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'!
>     +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:15'!
>     - self inform: 'line 3 branch master'.
>     + self inform: 'line 3 branch b4'.
> $ git commit -am "line 3 branch b4"
>
> $ git diff b1
> $ git merge b1
> $ cat some.st
>      ==> CONFLICT (content): Merge conflict in some.st
>
> $ git merge --abort
>
>
> So naive question... How does Monticello deal with such a situation between b3 & b4?
>
> Left as an exercise is pushing branches b3 & b4 to a git-service-provider,
> then issue a PR merging b3 into master, followed up a PR merging b4 into master.
>
> If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE
> on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc),
> in a way compatible with libgit, there may be a better case for calling B.S. on Tonel's lack of timestamps.
>
> I do remember watching the Pharo community struggle for many months with the above issue
> and it was really impeding git uptake by users.  I know I got burnt and I didn't transition to using git from within Pharo until it was resolved by Tonel.
> My memory of mail list discussions was that the decision to drop timestamps wasn't taken lightly,
> but seemed like the only practical way to move forward into a git world.
>
> HTH,
> cheers -ben
>


More information about the Vm-dev mailing list