2015-07-08 15:25 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 08 Jul 2015, at 15:19, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-07-08 15:11 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:
Our âcodingâ atoms are methods, not classes. Having method per file we can trace the history of changes with method detail, not class.
That I understand.
Now⦠you are complaining in the wrong problem.
Well⦠Having one file per method seems to be very problematic after all.
It's not ;)
FileTree meta information (who causes your merge problems) is needed *just* to keep monticello compatibility. Thatâs what is plain wrong and should be at least optional :)
I would happily integrate a âPlainFileTreeâ protocol (without monticello information) as an option, if someone provides such extension. Crap, I could make it myself if I have the time!⦠maybe next insomnia night :P
We can work on this next week. I am fed up to hear âwhy you guys are not using github?"
It's extremely easy to do.
Most of the code is ready for it.
But since there is no real push to get Pharo under git for now, I've left it as it is. In part because some are using FileTree directly and they need that compatibility level.
youâre wrong :) I feel the pain each time I need to provide a âwe are not ready yetâ.
You are not ready yet. I am long past the ready point ... So I'm letting you wait for libcgit integration and the perfect time to be ready.
As I said⦠real reason we are not ready is because we are still trying to mix to words, in ways no one actually needs.
So please⦠push!
I do :) Pushing for OSProcess corrections is that; GitFileTree as it is a satisfactory solution for the time being.
Esteban
ps: and btw⦠there is no reason why we cannot keep âmc-file-treeâ along with a âplain-file-treeâ both alive. As I said⦠I just can image very few cases when we *actually* need that compatibility.
Yes, but, since all the issues have been resolved (merge and all), I don't see the value ;) The barriers are in the Pharo team choices at the moment. Thierry