> On 08 Jul 2015, at 15:19, Thierry Goubier <[email protected]> wrote: > > > > 2015-07-08 15:11 GMT+02:00 Alexandre Bergel <[email protected] > <mailto:[email protected]>>: > > 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”. 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! 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. > > Thierry
