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

Bernhard Pieber bernhard at pieber.com
Sat Jan 18 11:44:10 UTC 2020


Hi Ben,

Thanks for taking the time to explain the issue in more detail.

There is one thing I don't understand. When someone is using Git anyway why bother writing MCZs in the first place when the only way to do that causes difficult to spot problems in Squeak?

That's an honest question. I am not putting blame on anyone. I use Git almost daily and can see the potential upsides, especially GitHub and PRs. (I convinced Juan to use Git in Cuis for external packages - mainly because there exists no full port of Monticello in Cuis.)

Bernhard

> Am 14.01.2020 um 18:18 schrieb Ben Coman <btc at openInWorld.com>:
> 
> 
> 
> 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 3 branch master'.
>     + self inform: 'line 3 branch b3'.
> $ git commit -am "line 3 branch b3"
> 
> $ 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