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

[Nicolas Cellier]

Hi Ben,
MC does handle a method as an atom. So 2 branches changing the same method
=> conflict.
git has no idea of what a class or method is. It sort of handle lines of
code as atom. This is arbitrary but works with most languages.
IMO, it's not a big problem, concurrent changes on one method require human
review.

Problem of metadata in filetree mostly came from the fact that all-metadata
of whole package was in a single line of a single file...
Even with that, Thierry Goubier did provide a git hook that did resolve 99%
of the false metadata conflicts, it's just that it was never
used/integrated.
http://forum.world.st/Glass-git-merge-driver-for-FileTree-td4758204.html
https://github.com/ThierryGoubier/GitFileTree-MergeDriver
The decision to kill metadata is understandable if in the long term you
decide to rely EXCLUSIVELY on VCS metadata.
But it means that you EXPLICITELY do not want to support compatibility with
MC.
That's what Eliot is calling passive aggressive.

So I don't buy the conflict argument.
In France we say: "quand on veut tuer son chien, on l'accuse de la rage".


Le mar. 14 janv. 2020 à 18:23, Ben Coman <btc at openinworld.com> a écrit :

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