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

[Nicolas Cellier]

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

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