2014-04-25 11:26 GMT+02:00 Esteban Lorenzano <estebanlm@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 mc/VMMaker-oscog.package/monticello.meta/version 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 package-cache

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 operation 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. Cheers

On 25 Apr 2014, at 01:16, Nicolas Cellier < nicolas.cellier.aka.nice@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...

2014-04-25 17:38 GMT+02:00 GOUBIER Thierry <thierry.goubier@cea.fr>:

Hi Nicolas,

from what you describe (double merge: one in git, one in MC), I wonder if my decision to maintain compatibility between gitfiletree and FileTree by writing the metadata (version / methodProperties) in gitfiletree is a good thing?

Thierry

Very good question indeed. This is spoiling the efficiency of git for merging... I think that the answer is yes though, because not every one is using git (think Eliot's branch). Esteban is not publishing the MC packages back on SmalltalkHub for nothing. Those MC package would not be usable if they loosed their history, and I'm not sure that we are ready to loose that... Yet, resolving the (real code) merge conflicts in an external tool does not feel so cool to me, I'd like to specify git mergetool --pharo ;) Another way would be to not attempt a merge at all via git, it would be simpler to just pick the mc package somewhere, but I don't like it, we're loosing git traceability (and those nice github networks). Otherwise, if development was exclusively git driven, then we would be more comfortable with git tools. But still, we have the image which is a working copy, and not necessarily in sync with gitfiletree, so we have a more complex process than file based environments anyway : one more indirection. image <-> files <-> staged files <-> repo There is still one super-cool feature where git shines that we can use: jumping from one branch to another (modulo the image sync with files), the most usefull one IMO when we are mixing external platform files and Smalltalk code that require some sync. Nicolas ------------------------------

*De :* Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] *Envoyé :* vendredi 25 avril 2014 15:46 *À :* Pharo Development List *Objet :* Re: [Pharo-dev] Modifications to be integrated in Pharo 3.0 VM

2014-04-25 11:26 GMT+02:00 Esteban Lorenzano <estebanlm@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 mc/VMMaker-oscog.package/monticello.meta/version

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 package-cache

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 operation 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.

Cheers