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

Ben Coman btc at openinworld.com
Tue Jan 14 17:18:09 UTC 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200115/72496b6f/attachment.html>


More information about the Vm-dev mailing list