On 01/28/2016 12:55 AM, Christophe Demarey 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).
Agreed ....
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.
On this point I think that we will always want to support multiple disk
formats .... in a perfect world, there is no reason not to have one file
per method and no Monticello meta data ... but perfection does not exist.
Monticello meta data was included in FileTree because it was needed over
the last 4 years so that developers could dip there toes into using git
without completely abandoning Monticello .... Now that we are gaining a
critical mass of users and the tool support is starting to show up,
dropping the meta data is a practical thing to do ... but there is code
committed on github that hasn't been updated in years that is still
being used and Monticello meta data is still present, so it is necessary
to "support the older formats".
The one file per method was chosen for two reasons.
The first reason has to do with the fact that disk based SCMs are
designed manage files as atomic units and in Smalltalk the method is the
atomic unit for source code ... it is very convenient to be able to
leverage native SCN files for a) versioning files and b) maintaining
version history for a method as it moves from class to class ...
The second reason has to do with the fact that there is no cross
platform fileout format for Smalltalk. Chunk format comes is "common"
but chunk format also relies on executing Smalltalk code to define
classes and there hasn't been a standard class creation method since the
second Smalltalk implementation showed up on the planet ... Technically,
class and method definitions can be derived from a file per class
approach, but without a standardized file format you end up with each
dialect isolating itself from the others and this is not desirable nor
necessary ... It just takes more work to come up with a file format that
can accommodate the different needs of the different dialects .... the
one method per file and a generic properties file for class
definitions[1] and the provision for allowing additional platform
specific property files and directories (like monticello meta data)
simplified the whole process ...
So I would like changing the disk format for sharing source code to be a
multi-platform effort - which means that format that is chosen is
flexible enough to allow dialects to include the meta data that they
need ... It is important to note that there has never been a guarantees
that all platforms would PRESERVE and WRITE foreign meta data ... the
only provision that exists is that ALL platforms can READ the format
while ignoring anything it doesn't recognize ....
Dale
[1]
https://raw.githubusercontent.com/CampSmalltalk/Cypress/master/img/CypressStructure-STIC2012.png
