Le 28 janv. 2016 à 09:34, Sven Van Caekenberghe a écrit :

> 
>> On 28 Jan 2016, at 09:23, Christophe Demarey <christophe.dema...@inria.fr> 
>> 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to