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

[Ben Coman]

On Mon, 20 Jan 2020 at 16:47, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
>
>
> Hi Ben,
>
>
> Le dim. 19 janv. 2020 à 09:43, Ben Coman <btc at openinworld.com> a écrit :
>>
>>
>> On Thu, 16 Jan 2020 at 06:47, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> >
>> >
>> > Hi Ben!
>> >
>> > On Wed, 15 Jan 2020, Ben Coman wrote:
>> >
>> > >
>> > > On Wed, 15 Jan 2020 at 01:18, Ben Coman <btc at openinworld.com> wrote:
>> > >>
>> > >>
>> >
>> > snip
>> >
>> > >>
>> > >>
>> > >> 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),
>> >
>> > Why do you want these to "AUTO RESOLVE"?
>> > If the same method is modified in two different branches, it's a must to
>> > check whether those changes are compatible or not, isn't it?
>>
>> Because the merge of PRs is happening on a CI server where there is no
>> human interaction.
>> Tests take care of the issue of compatibility.
>>
> I have to disagree here.
> Tests do not replace human review, they just complement it

A PR does get human review.  To review a PR I would merge that PR into my image,
then later discuss on github about whether the PR should be changed or merged.
When the PR is approved and someone clicks the github <Merge> button.
The CI server then bootstraps Pharo from scratch and repeats the same
PR merge that I did in my image,
at which point conflicts requiring human intervention would be awkward.

>
>> btw, Did you run through my example on your own system?
>> If not, please do.  :)   Its easy to skim the text without getting a
>> real feel for it,
>> and indeed, in re-reading my example and my point doesn't leap out at me.
>>
>> My point was that that the FIRST EXPERIMENT demonstrates two branches
>> with "different changes to the same method without updating the times
>> stamp"
>> doesn't cause a merge problem.  The result method contains both changes.
>>
>> The SECOND EXPERIMENT makes the identical changes, but this time
>> updates the timestamp.  Two updates to the same-line causes a
>> conflict.
>>
>> cheers -ben
>
>
> Yes, we agree that in some cases line based diff may avoid some conflicts.
> But as we said, we want human review anyway in case of such concurrent method change.
> That's true that the non conflicting case would require one more commit or a rebase before merging the PR.


> But in Smalltalk, methods are rather short, so how often is your crafted example going to happen in real world?

I had the same thought about short methods. My example would rarely
happen in practice.
An explanation was requested for "how timestamps ... introduce
change/conflict in git."
In the time I had available to answer, my crafted example was just the
simplest I could come up with.

cheers -ben