Hi Dale, I am trying to understand this a little better. If a package containing metadata would be changed using a dialect which cannot interpret the metadata, wouldn’t or at least couldn’t it be broken or lost afterwards for a dialect which tries to interpret the metadata? At least if my assumption is correct that the metadata is related to the code in some way?
Bernhard > Am 28.01.2016 um 21:28 schrieb Dale Henrichs > <[email protected]>: > On 01/28/2016 12:55 AM, Christophe Demarey wrote: >> Le 28 janv. 2016 à 09:34, Sven Van Caekenberghe a écrit : >> 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
