> On 28 Jan 2016, at 09:55, Christophe Demarey <[email protected]> > wrote: > > > Le 28 janv. 2016 à 09:34, Sven Van Caekenberghe a écrit : > >> >>> On 28 Jan 2016, at 09:23, Christophe Demarey <[email protected]> >>> wrote: >>> >>> I read too fast. >>> But my comment is still true. >>> We also want a new version browser. Monticello browser is too tied to ... >>> Monticello. We would like a better approach for both git and monticello. >> >> It is totally wrong to put Git and Monticello at the same level, they are >> related but different things. >> >> Monticello models our code and your changes to it. It also has a way of >> putting a package into a persistent representation that can be copied >> around. An MC server is nothing more than storage. >> >> Filetree is another way of doing that, using a different representation, but >> it still needs MC for the high level stuff. Git is versioned storage. And >> there is a conflict there, yes. >> >> But throwing away the MC code and changes model would leave you with file >> outs. You do not want to go there, really. Never, ever. > > I fully agree. > The problem is that Monticello does too much things: code representation, > versioning, loading of the code and call of #initialize methods, etc. > We want to keep a code representation but the question that comes: is it the > better code representation? We also have ring, ficus (hierarchical model on > top of ring). For code representation, we would like to represent code (from > packages to method source code) for multiple versions, in a hierarchical way > (to be able to query easily), potentially coming from a remote environment. > We also need to split the loading part (loading from the code representation) > and the serialization / deserialization part. > > At the end, we want an uniform way to represent code (not SCM related), a > common API for versioning and different backends (git, Monticello). By the > way, we can add the storage format: there are already different versions of > the filetree format (with metadata, without, one file per method, one file > per class). At some point, we need to handle this point of variability.
Excellent summary. Lots of work ;-)
