[Pharo-dev] Modifications to be integrated in Pharo 3.0 VM

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Apr 25 09:46:00 EDT 2014

2014-04-25 11:26 GMT+02:00 Esteban Lorenzano <estebanlm at gmail.com>:

> Hi Nicolas,
> I cannot approve your pull requests because there are conflicts (I
> suspects is all the same conflict).
> can you fix them?
> thanks,
> Esteban

Hi Esteban,
I don't think there is a single source code conflict...
But of course, there is allways 1 conflict : the MC meta information

Since the branch was not forked from latest master, every other feature
branch will rot as soon as you integrate the first one.
That's the major limitation of gitfiletree.

The way I found to workaround this is to :

git checkout master
start an image in interactive mode, make sure to have current version from
gitfiletree loaded

git fetch someRepo someBranch
git checkout someBranch
>From the image, open git file tree and copy modifiedPackage in local MC

git checkout master
git merge someBranch
git mergetool
answer remote/local as you like for .meta/version and say [y] it's fixed
(you'll overwrite it soon after)

>From the image MC merge modifiedPackage copy from the package-cache
Republish the merged package in gitfiletree
git commit -a -m "Merge pull request #... (fix someBranch)"

That's a bit heavier than a pure MC workflow, but it's bearable IMO...

Tell me if this sounds clear enough.

Another possibility is to do the exact mirror of this operation : merge
master branch in each someBranch.
But I don't think it's viable :
1) If I have 10 branches, and don't know in which order you want to
integrate, then I'll have to do it 10+9+8+... times - that's 45 times this
2) If I know the order, I'll do that job in a single someBranch, it is
exactly the mirror of above operation : merge master into someBranch rather
than someBranch into master. But then it's both fragile (it can rot at any
time if you decide to interleave another fix), and it is against the spirit
of git : the feature branch should carry the minimum of changes IMO.

The only advantage of this approach is to reduce the bottleneck effect by
reducing the work performed by the integrator, especially if you are alone
to cope with this burden... Unfortunately I'm out of time right now.

I wanted to blog about it, but blogging is taking time... Hope my
explanations help.


> On 25 Apr 2014, at 01:16, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
> I think this fix is essential and should be applied before releasing Pharo
> VM:
> https://github.com/pharo-project/pharo-vm/pull/31
> Those are optionals but would be nice to have:
> https://github.com/pharo-project/pharo-vm/pull/32
> https://github.com/pharo-project/pharo-vm/pull/33
> https://github.com/pharo-project/pharo-vm/pull/34
> https://github.com/pharo-project/pharo-vm/pull/42
> Those can wait but are ready and not dangerous IMO:
> https://github.com/pharo-project/pharo-vm/pull/37
> https://github.com/pharo-project/pharo-vm/pull/39
> https://github.com/pharo-project/pharo-vm/pull/40
> This one works perfectly for me but failed on the CI server I really
> wonder why...
> https://github.com/pharo-project/pharo-vm/pull/41
> This one would be nice to have too but does not fully work on my mac.
> I really fail to understand why...
> The exact same code in Cog branch works perfectly with same compiler
> (slightly different options maybe?)
> I'd be curious to know if all Kernel-Number tests pass when compiled by
> someone else.
> https://github.com/pharo-project/pharo-vm/pull/35
> And last, the compiler flags should be fixed on MacOSX for bug
> https://pharo.fogbugz.com/f/cases/11130
> Or clang replaced by an older gcc...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140425/5612be42/attachment-0002.html>

More information about the Pharo-dev mailing list