Re: feedback on using JSON to specify baselines for git repository]

stephane ducasse wrote:

Yes. In the beginning, the git (or SVN) tools that support the merge would be used to do the source level merges. Over time, if it is successful I imagine that image-level for doing the merge would be developed…
    

does it mean dropping all the merge tools from the image? and the three way merge?

  

| can you give one example?
| Because we want to have a real code representation exchange format
| for logging changes:
| 	having method, and class is not enough.
| 	Now we have ring so we could expect that a new logger would log
| 	better the actions we are doing

The JSON-based format is for Metacello specifications only.
    

ah for Metacello so I'm even more confused. So not spec package: requires: []… anymore.
So we will have write metacello spec in JSON? 

So in addition the spec in metacello we will have to load a JSON or YAML parser?

  

Using a class for ConfigurationOfXXX has been a convenient and expedient mechanism for defining configurations in Metacello, but using executable code to define a specification is not ideal:

 - one cannot extract specification information without executing 
   code is bad from a security point of view
    

+100 My career has been mostly IT system administration more than programming.  In today's world, anything that helps security is greatly appreciated. I agree with configurations not being executable code.

 - tools have to create classes and generate methods in order to 
   write a specification, again not an ideal situation.
    

Sure but you do not have to execute code to se the smalltalk syntax as a declarative one.
You do not need a JSON syntax to get a tree structure.

The problem of metacello is not the execution but the fact that it is not used declaratively.
Because 
if you have a tree in JSON

[
 	{"baseline" : [
		{"common" :
			[
 			{"package" : {
 				"name" : "MonticelloFileTree-Core"}},

then you can have
	Baseline named: 'Common'
		addElement: 	
			Package named: 'name'

You can use the smalltalk syntax as a declarative one. This is totally orthogonal. 
So I really do not understand why JSON is better except that you will need yet another parser.
  

To familiarise myself with this I read on json.org ...

JSON is built on two structures:

• "A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

and I was thinking that Pharo syntax has both of these already, as shown by evaluating...

{    'baseline' ->
    {    'common' ->
        {    'package' ->
            {    'name' -> 'MonticelloFileTree-Core' .
            }.
            'group' ->
            {    'name' -> 'default' .
                'includes' -> { 'MonticelloFileTree-Core' . 'someOtherPackage' }.
            }.
        }.
"with just a small alternative using symbols"  
         'gemstone' ->
        {    #package  ->
            {    #name -> 'MonticelloTree-Core' .
                #includes -> { 'MonticelloFileTree-GemStone-Extensions' } .
            }.
            #package ->
            {    #name -> 'MonticelloFileTree-GemStone-Extensions' .
                #includes -> { 'MonticelloFileTree-Core' } .           
            }.
        }.
    }.
}
explore

...so perhaps the built-in parser could be used for this, with a tweak constraining it to literals-only to avoid code execution.
However I notice contents of #explore shows:
    ''baseline''->{(''common''->((Array new: 2) at: 1 put: (''package''->((Array new: 1)
which I'm not sure how this generated code relates to the security implications of executable code in the specification.

With the file based SCM systems (SVN and GIT) the Metacello configuration does not have to become the data base for all versions of the project.
    

DNU

  

It is only necessary for Metacello to specify required projects and package dependencies, basically all we need is a baseline specification. 
    

I do not see why. 
Because if I want to rely on specific versions or latest dev….


  

For a single baseline specification, one would need only one method in the current class-based system so including a class in the mix is basically overkill. I considered using a doit to define the specification, but thought that now would be a good time to go for the structured file to specify the baseline.
    

you are losing me and I feel immensely sad because I have the impression that this is the revolution in metacello 
and that we will have to reinvent the wheel and without a map packages are nothing …
So you killed my energy. 

  

| 
| That I do not know. For me I do not see problems beside resources
| management. I do not see the difference
| for the rest because I can merge and the merge works quite well.
| What I know is that we technical people are excited by technology.
| People are telling me that git is wonderful
| and that I should stop using svn. Well so far Git just alienates me
| and I need a bad UI to manage simple pull requests.

You are talking about merging individual mcz files working well and I agree. Monticello is a very nice system for dealing with versioned files. 

As it stands today, there is no project merge capability. There is really no way for developers to create a branch at the project level, work for hours, days or weeks independently and then come back and merge their configuration changes and package changes. If you figured out which sets of packages changed, you would be able to merge the smalltalk code, but if you had made changes to the baselines and versions there is no merge capability…
    

ah that.
But I do not see how Git can provide magic there. 
To me git deal with texts or if it does not then it means that the logic can be apply to Metacello specs as well. 


  

When I started out with Metacello, I imagined that merging would be straightforward source code comparison. Today I don't think so. If you recall last spring Alexandre's style of using Metacello was to create a new project version for each commit. The basic problem wasn't that it was "wrong" to do so, it just made doing any sort of source-based merge impossible.
    

I do not get it.
You have two spec trees and you merge them. So I do not see why a git textual merge would succeeds and if it succeeds
why a merge based on objects = Metacello spec would not work. 



  

In order to merge two branches of a Metacello project that involve changes to more than just the same version, one must create two or three version specifications in memory at the same time. For an mcz file, you can keep multiple definitions because the mcz file is a serialized version of the meta data. For metacello, we have to load a class and execute a method for each of the three versions and if the version of the class in the initial image is dirty? What do we do? 
    

I think that git is not the solution to the problem. The solution to the problem is to rethink what is a metacello spec.
Personally I see a metacello spec as a tree of declarations. Now if the three is generated then indeed this is a problem
because you have to execute the program but I do not see why the solution that would solved the problem by using git would not solve the problem without git. I think that the solution looks orthogonal to the software artifact used but may be I'm wrong. 

  

Now technically there is a solution to this merge problem, but it involves at a minimum creating a completely different file format for configurations, not to mention a whole set of new tools ….
    

Why not.
Because we have a declarative Smalltalk syntax.
Personnally I hate that I have to define method on a configuration like loadLatest load….
a ConfigurationOf is about data not execution. 

  

As for SVN and GIT, I think that the jury is still out on whether SVN is better or worse than GIT ... there isn't really a clear winner there.

The bulk of the work that I have and will be doing will be equally applicable to SVN and GIT ... we use SVN within GemStone and I intend to use this new work for managing the GemStone GLASS source in SVN directly rather than versioning a directory of mcz files .... 

I believe that SVN and GIT can be used interchangeably especially with the initial versions of my work, since I will be relying on the developers using the SVN/GIT tools for managing their repositories.

On the other hand GitHub has a lot of features that we don't have in SqueakSource that would be real useful to have ... so because of GitHub, I am interested in making a push directed at git.
    

Ok but I think that relying on an external logic to merge metacello configuration looks like dropping the ball on the floor
while now we could revisit and really simplify metacello and freeze in declaration the configuration.
May be I'm wrong but this is what you want to do with your git approach.

So may be I got it totally wrong but to me. The problem is in the executability of the DSL you built and the fact that you 
need to interpret the data to get it. while with a structural spec and a fixed semantics I think that merge should be possible.

  

I should amend my statement to include git and svn ... being able to manage projects at the source level where one can create project level branches and have a chance for merging the changes between two arbitrary branches will be a major step forward.

With mcz files the best one can do is manage a version of the Monticello directory, but all of the source is completely opaque.

In the file-base Monticello the meta data is stored in plain files and directory structure and the ancestry is taken care of the the underlying SCM (git or svn). For the FileTree package structure, the ancestry will be kept around only to make it possible to move the package into and out of a file-based repository without losing the ancestry (because it is required for Monticello-level merging).
    

You lost me again.
I thought you wanted to put only metacello in git.

Do you mean that you would version method as git objects and use the git ancestry management to merge?




  

Ben,

If we use the Smalltalk array constructor and association, then we are back to having to execute an arbitrary Smalltalk expression.

I need a file format that will be parsed, not executed .... which is why I'm looking towards JSON or YAML ...

Dale

----- Original Message -----
| From: "Ben Coman" <[hidden email]>
| To: [hidden email]
| Sent: Sunday, February 5, 2012 8:57:10 PM
| Subject: Re: [Metacello] feedback on using JSON to specify baselines for git repository]
|
|
| stephane ducasse wrote:
|
|
|
| Yes. In the beginning, the git (or SVN) tools that support the merge
| would be used to do the source level merges. Over time, if it is
| successful I imagine that image-level for doing the merge would be
| developed… does it mean dropping all the merge tools from the image?
| and the three way merge?
|
| | can you give one example?
| | Because we want to have a real code representation exchange format
| | for logging changes:
| | having method, and class is not enough.
| | Now we have ring so we could expect that a new logger would log
| | better the actions we are doing
|
| The JSON-based format is for Metacello specifications only. ah for
| Metacello so I'm even more confused. So not spec package: requires:
| []… anymore.
| So we will have write metacello spec in JSON?
|
| So in addition the spec in metacello we will have to load a JSON or
| YAML parser?
|
| Using a class for ConfigurationOfXXX has been a convenient and
| expedient mechanism for defining configurations in Metacello, but
| using executable code to define a specification is not ideal:
|
|  - one cannot extract specification information without executing
|    code is bad from a security point of view +100 My career has been
|    mostly IT system administration more than programming. In today's
|    world, anything that helps security is greatly appreciated. I
|    agree with configurations not being executable code.
|
|
|
|
|
| - tools have to create classes and generate methods in order to
|    write a specification, again not an ideal situation. Sure but you
|    do not have to execute code to se the smalltalk syntax as a
|    declarative one.
| You do not need a JSON syntax to get a tree structure.
|
| The problem of metacello is not the execution but the fact that it is
| not used declaratively.
| Because
| if you have a tree in JSON
|
| [
|   {"baseline" : [
| {"common" :
| [
|   {"package" : {
|   "name" : "MonticelloFileTree-Core"}},
|
| then you can have
| Baseline named: 'Common'
| addElement:
| Package named: 'name'
|
| You can use the smalltalk syntax as a declarative one. This is
| totally orthogonal.
| So I really do not understand why JSON is better except that you will
| need yet another parser.
| To familiarise myself with this I read on json.org ...
|
|
| JSON is built on two structures:
|
|
|
|     * "A collection of name/value pairs. In various languages, this
|     is realized as an object , record, struct, dictionary, hash
|     table, keyed list, or associative array.
|     * An ordered list of values. In most languages, this is realized
|     as an array , vector, list, or sequence.
| and I was thinking that Pharo syntax has both of these already, as
| shown by evaluating...
|
| { 'baseline' ->
| { 'common' ->
| { 'package' ->
| { 'name' -> 'MonticelloFileTree-Core' .
| }.
| 'group' ->
| { 'name' -> 'default' .
| 'includes' -> { 'MonticelloFileTree-Core' . 'someOtherPackage' }.
| }.
| }.
| "with just a small alternative using symbols"
| 'gemstone' ->
| { #package ->
| { #name -> 'MonticelloTree-Core' .
| #includes -> { 'MonticelloFileTree-GemStone-Extensions' } .
| }.
| #package ->
| { #name -> 'MonticelloFileTree-GemStone-Extensions' .
| #includes -> { 'MonticelloFileTree-Core' } .
| }.
| }.
| }.
| }
| explore
|
| ...so perhaps the built-in parser could be used for this, with a
| tweak constraining it to literals-only to avoid code execution.
| However I notice contents of #explore shows:
| ''baseline''->{(''common''->((Array new: 2) at: 1 put:
| (''package''->((Array new: 1)
| which I'm not sure how this generated code relates to the security
| implications of executable code in the specification.
|
|
|
|
|
| With the file based SCM systems (SVN and GIT) the Metacello
| configuration does not have to become the data base for all versions
| of the project. DNU
|
| It is only necessary for Metacello to specify required projects and
| package dependencies, basically all we need is a baseline
| specification. I do not see why.
| Because if I want to rely on specific versions or latest dev….
|
| For a single baseline specification, one would need only one method
| in the current class-based system so including a class in the mix is
| basically overkill. I considered using a doit to define the
| specification, but thought that now would be a good time to go for
| the structured file to specify the baseline. you are losing me and I
| feel immensely sad because I have the impression that this is the
| revolution in metacello
| and that we will have to reinvent the wheel and without a map
| packages are nothing …
| So you killed my energy.
|
| |
| | That I do not know. For me I do not see problems beside resources
| | management. I do not see the difference
| | for the rest because I can merge and the merge works quite well.
| | What I know is that we technical people are excited by technology.
| | People are telling me that git is wonderful
| | and that I should stop using svn. Well so far Git just alienates me
| | and I need a bad UI to manage simple pull requests.
|
| You are talking about merging individual mcz files working well and I
| agree. Monticello is a very nice system for dealing with versioned
| files.
|
| As it stands today, there is no project merge capability. There is
| really no way for developers to create a branch at the project
| level, work for hours, days or weeks independently and then come
| back and merge their configuration changes and package changes. If
| you figured out which sets of packages changed, you would be able to
| merge the smalltalk code, but if you had made changes to the
| baselines and versions there is no merge capability… ah that.
| But I do not see how Git can provide magic there.
| To me git deal with texts or if it does not then it means that the
| logic can be apply to Metacello specs as well.
|
| When I started out with Metacello, I imagined that merging would be
| straightforward source code comparison. Today I don't think so. If
| you recall last spring Alexandre's style of using Metacello was to
| create a new project version for each commit. The basic problem
| wasn't that it was "wrong" to do so, it just made doing any sort of
| source-based merge impossible. I do not get it.
| You have two spec trees and you merge them. So I do not see why a git
| textual merge would succeeds and if it succeeds
| why a merge based on objects = Metacello spec would not work.
|
| In order to merge two branches of a Metacello project that involve
| changes to more than just the same version, one must create two or
| three version specifications in memory at the same time. For an mcz
| file, you can keep multiple definitions because the mcz file is a
| serialized version of the meta data. For metacello, we have to load
| a class and execute a method for each of the three versions and if
| the version of the class in the initial image is dirty? What do we
| do? I think that git is not the solution to the problem. The
| solution to the problem is to rethink what is a metacello spec.
| Personally I see a metacello spec as a tree of declarations. Now if
| the three is generated then indeed this is a problem
| because you have to execute the program but I do not see why the
| solution that would solved the problem by using git would not solve
| the problem without git. I think that the solution looks orthogonal
| to the software artifact used but may be I'm wrong.
|
| Now technically there is a solution to this merge problem, but it
| involves at a minimum creating a completely different file format
| for configurations, not to mention a whole set of new tools …. Why
| not.
| Because we have a declarative Smalltalk syntax.
| Personnally I hate that I have to define method on a configuration
| like loadLatest load….
| a ConfigurationOf is about data not execution.
|
| As for SVN and GIT, I think that the jury is still out on whether SVN
| is better or worse than GIT ... there isn't really a clear winner
| there.
|
| The bulk of the work that I have and will be doing will be equally
| applicable to SVN and GIT ... we use SVN within GemStone and I
| intend to use this new work for managing the GemStone GLASS source
| in SVN directly rather than versioning a directory of mcz files ....
|
| I believe that SVN and GIT can be used interchangeably especially
| with the initial versions of my work, since I will be relying on the
| developers using the SVN/GIT tools for managing their repositories.
|
| On the other hand GitHub has a lot of features that we don't have in
| SqueakSource that would be real useful to have ... so because of
| GitHub, I am interested in making a push directed at git. Ok but I
| think that relying on an external logic to merge metacello
| configuration looks like dropping the ball on the floor
| while now we could revisit and really simplify metacello and freeze
| in declaration the configuration.
| May be I'm wrong but this is what you want to do with your git
| approach.
|
| So may be I got it totally wrong but to me. The problem is in the
| executability of the DSL you built and the fact that you
| need to interpret the data to get it. while with a structural spec
| and a fixed semantics I think that merge should be possible.
|
| I should amend my statement to include git and svn ... being able to
| manage projects at the source level where one can create project
| level branches and have a chance for merging the changes between two
| arbitrary branches will be a major step forward.
|
| With mcz files the best one can do is manage a version of the
| Monticello directory, but all of the source is completely opaque.
|
| In the file-base Monticello the meta data is stored in plain files
| and directory structure and the ancestry is taken care of the the
| underlying SCM (git or svn). For the FileTree package structure, the
| ancestry will be kept around only to make it possible to move the
| package into and out of a file-based repository without losing the
| ancestry (because it is required for Monticello-level merging). You
| lost me again.
| I thought you wanted to put only metacello in git.
|
| Do you mean that you would version method as git objects and use the
| git ancestry management to merge?
|

On Feb 6, 2012, at 6:15 PM, Dale Henrichs wrote:

> Ben,
>
> If we use the Smalltalk array constructor and association, then we are back to having to execute an arbitrary Smalltalk expression.
>
> I need a file format that will be parsed, not executed

can you explain why?
Because I discussed with camillo about git today and I do not see why you cannot use smalltalk literal array
or any smalltalk expression for what you are looking for.

Stef

I hope that I've just covered this in my other post...

----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 6, 2012 9:27:28 AM
| Subject: Re: [Metacello] feedback on using JSON to specify baselines for git repository]
|
|
| On Feb 6, 2012, at 6:15 PM, Dale Henrichs wrote:
|
| > Ben,
| >
| > If we use the Smalltalk array constructor and association, then we
| > are back to having to execute an arbitrary Smalltalk expression.
| >
| > I need a file format that will be parsed, not executed
|
| can you explain why?
| Because I discussed with camillo about git today and I do not see why
| you cannot use smalltalk literal array
| or any smalltalk expression for what you are looking for.
|
| Stef
|
| > .... which is why I'm looking towards JSON or YAML ...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Ben Coman" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Sunday, February 5, 2012 8:57:10 PM
| > | Subject: Re: [Metacello] feedback on using JSON to specify
| > | baselines for git repository]
| > |
| > |
| > | stephane ducasse wrote:
| > |
| > |
| > |
| > | Yes. In the beginning, the git (or SVN) tools that support the
| > | merge
| > | would be used to do the source level merges. Over time, if it is
| > | successful I imagine that image-level for doing the merge would
| > | be
| > | developed… does it mean dropping all the merge tools from the
| > | image?
| > | and the three way merge?
| > |
| > | | can you give one example?
| > | | Because we want to have a real code representation exchange
| > | | format
| > | | for logging changes:
| > | | having method, and class is not enough.
| > | | Now we have ring so we could expect that a new logger would
| > | | log
| > | | better the actions we are doing
| > |
| > | The JSON-based format is for Metacello specifications only. ah
| > | for
| > | Metacello so I'm even more confused. So not spec package:
| > | requires:
| > | []… anymore.
| > | So we will have write metacello spec in JSON?
| > |
| > | So in addition the spec in metacello we will have to load a JSON
| > | or
| > | YAML parser?
| > |
| > | Using a class for ConfigurationOfXXX has been a convenient and
| > | expedient mechanism for defining configurations in Metacello, but
| > | using executable code to define a specification is not ideal:
| > |
| > |  - one cannot extract specification information without executing
| > |    code is bad from a security point of view +100 My career has
| > |    been
| > |    mostly IT system administration more than programming. In
| > |    today's
| > |    world, anything that helps security is greatly appreciated. I
| > |    agree with configurations not being executable code.
| > |
| > |
| > |
| > |
| > |
| > | - tools have to create classes and generate methods in order to
| > |    write a specification, again not an ideal situation. Sure but
| > |    you
| > |    do not have to execute code to se the smalltalk syntax as a
| > |    declarative one.
| > | You do not need a JSON syntax to get a tree structure.
| > |
| > | The problem of metacello is not the execution but the fact that
| > | it is
| > | not used declaratively.
| > | Because
| > | if you have a tree in JSON
| > |
| > | [
| > |   {"baseline" : [
| > | {"common" :
| > | [
| > |   {"package" : {
| > |   "name" : "MonticelloFileTree-Core"}},
| > |
| > | then you can have
| > | Baseline named: 'Common'
| > | addElement:
| > | Package named: 'name'
| > |
| > | You can use the smalltalk syntax as a declarative one. This is
| > | totally orthogonal.
| > | So I really do not understand why JSON is better except that you
| > | will
| > | need yet another parser.
| > | To familiarise myself with this I read on json.org ...
| > |
| > |
| > | JSON is built on two structures:
| > |
| > |
| > |
| > |     * "A collection of name/value pairs. In various languages,
| > |     this
| > |     is realized as an object , record, struct, dictionary, hash
| > |     table, keyed list, or associative array.
| > |     * An ordered list of values. In most languages, this is
| > |     realized
| > |     as an array , vector, list, or sequence.
| > | and I was thinking that Pharo syntax has both of these already,
| > | as
| > | shown by evaluating...
| > |
| > | { 'baseline' ->
| > | { 'common' ->
| > | { 'package' ->
| > | { 'name' -> 'MonticelloFileTree-Core' .
| > | }.
| > | 'group' ->
| > | { 'name' -> 'default' .
| > | 'includes' -> { 'MonticelloFileTree-Core' . 'someOtherPackage' }.
| > | }.
| > | }.
| > | "with just a small alternative using symbols"
| > | 'gemstone' ->
| > | { #package ->
| > | { #name -> 'MonticelloTree-Core' .
| > | #includes -> { 'MonticelloFileTree-GemStone-Extensions' } .
| > | }.
| > | #package ->
| > | { #name -> 'MonticelloFileTree-GemStone-Extensions' .
| > | #includes -> { 'MonticelloFileTree-Core' } .
| > | }.
| > | }.
| > | }.
| > | }
| > | explore
| > |
| > | ...so perhaps the built-in parser could be used for this, with a
| > | tweak constraining it to literals-only to avoid code execution.
| > | However I notice contents of #explore shows:
| > | ''baseline''->{(''common''->((Array new: 2) at: 1 put:
| > | (''package''->((Array new: 1)
| > | which I'm not sure how this generated code relates to the
| > | security
| > | implications of executable code in the specification.
| > |
| > |
| > |
| > |
| > |
| > | With the file based SCM systems (SVN and GIT) the Metacello
| > | configuration does not have to become the data base for all
| > | versions
| > | of the project. DNU
| > |
| > | It is only necessary for Metacello to specify required projects
| > | and
| > | package dependencies, basically all we need is a baseline
| > | specification. I do not see why.
| > | Because if I want to rely on specific versions or latest dev….
| > |
| > | For a single baseline specification, one would need only one
| > | method
| > | in the current class-based system so including a class in the mix
| > | is
| > | basically overkill. I considered using a doit to define the
| > | specification, but thought that now would be a good time to go
| > | for
| > | the structured file to specify the baseline. you are losing me
| > | and I
| > | feel immensely sad because I have the impression that this is the
| > | revolution in metacello
| > | and that we will have to reinvent the wheel and without a map
| > | packages are nothing …
| > | So you killed my energy.
| > |
| > | |
| > | | That I do not know. For me I do not see problems beside
| > | | resources
| > | | management. I do not see the difference
| > | | for the rest because I can merge and the merge works quite
| > | | well.
| > | | What I know is that we technical people are excited by
| > | | technology.
| > | | People are telling me that git is wonderful
| > | | and that I should stop using svn. Well so far Git just
| > | | alienates me
| > | | and I need a bad UI to manage simple pull requests.
| > |
| > | You are talking about merging individual mcz files working well
| > | and I
| > | agree. Monticello is a very nice system for dealing with
| > | versioned
| > | files.
| > |
| > | As it stands today, there is no project merge capability. There
| > | is
| > | really no way for developers to create a branch at the project
| > | level, work for hours, days or weeks independently and then come
| > | back and merge their configuration changes and package changes.
| > | If
| > | you figured out which sets of packages changed, you would be able
| > | to
| > | merge the smalltalk code, but if you had made changes to the
| > | baselines and versions there is no merge capability… ah that.
| > | But I do not see how Git can provide magic there.
| > | To me git deal with texts or if it does not then it means that
| > | the
| > | logic can be apply to Metacello specs as well.
| > |
| > | When I started out with Metacello, I imagined that merging would
| > | be
| > | straightforward source code comparison. Today I don't think so.
| > | If
| > | you recall last spring Alexandre's style of using Metacello was
| > | to
| > | create a new project version for each commit. The basic problem
| > | wasn't that it was "wrong" to do so, it just made doing any sort
| > | of
| > | source-based merge impossible. I do not get it.
| > | You have two spec trees and you merge them. So I do not see why a
| > | git
| > | textual merge would succeeds and if it succeeds
| > | why a merge based on objects = Metacello spec would not work.
| > |
| > | In order to merge two branches of a Metacello project that
| > | involve
| > | changes to more than just the same version, one must create two
| > | or
| > | three version specifications in memory at the same time. For an
| > | mcz
| > | file, you can keep multiple definitions because the mcz file is a
| > | serialized version of the meta data. For metacello, we have to
| > | load
| > | a class and execute a method for each of the three versions and
| > | if
| > | the version of the class in the initial image is dirty? What do
| > | we
| > | do? I think that git is not the solution to the problem. The
| > | solution to the problem is to rethink what is a metacello spec.
| > | Personally I see a metacello spec as a tree of declarations. Now
| > | if
| > | the three is generated then indeed this is a problem
| > | because you have to execute the program but I do not see why the
| > | solution that would solved the problem by using git would not
| > | solve
| > | the problem without git. I think that the solution looks
| > | orthogonal
| > | to the software artifact used but may be I'm wrong.
| > |
| > | Now technically there is a solution to this merge problem, but it
| > | involves at a minimum creating a completely different file format
| > | for configurations, not to mention a whole set of new tools ….
| > | Why
| > | not.
| > | Because we have a declarative Smalltalk syntax.
| > | Personnally I hate that I have to define method on a
| > | configuration
| > | like loadLatest load….
| > | a ConfigurationOf is about data not execution.
| > |
| > | As for SVN and GIT, I think that the jury is still out on whether
| > | SVN
| > | is better or worse than GIT ... there isn't really a clear winner
| > | there.
| > |
| > | The bulk of the work that I have and will be doing will be
| > | equally
| > | applicable to SVN and GIT ... we use SVN within GemStone and I
| > | intend to use this new work for managing the GemStone GLASS
| > | source
| > | in SVN directly rather than versioning a directory of mcz files
| > | ....
| > |
| > | I believe that SVN and GIT can be used interchangeably especially
| > | with the initial versions of my work, since I will be relying on
| > | the
| > | developers using the SVN/GIT tools for managing their
| > | repositories.
| > |
| > | On the other hand GitHub has a lot of features that we don't have
| > | in
| > | SqueakSource that would be real useful to have ... so because of
| > | GitHub, I am interested in making a push directed at git. Ok but
| > | I
| > | think that relying on an external logic to merge metacello
| > | configuration looks like dropping the ball on the floor
| > | while now we could revisit and really simplify metacello and
| > | freeze
| > | in declaration the configuration.
| > | May be I'm wrong but this is what you want to do with your git
| > | approach.
| > |
| > | So may be I got it totally wrong but to me. The problem is in the
| > | executability of the DSL you built and the fact that you
| > | need to interpret the data to get it. while with a structural
| > | spec
| > | and a fixed semantics I think that merge should be possible.
| > |
| > | I should amend my statement to include git and svn ... being able
| > | to
| > | manage projects at the source level where one can create project
| > | level branches and have a chance for merging the changes between
| > | two
| > | arbitrary branches will be a major step forward.
| > |
| > | With mcz files the best one can do is manage a version of the
| > | Monticello directory, but all of the source is completely opaque.
| > |
| > | In the file-base Monticello the meta data is stored in plain
| > | files
| > | and directory structure and the ancestry is taken care of the the
| > | underlying SCM (git or svn). For the FileTree package structure,
| > | the
| > | ancestry will be kept around only to make it possible to move the
| > | package into and out of a file-based repository without losing
| > | the
| > | ancestry (because it is required for Monticello-level merging).
| > | You
| > | lost me again.
| > | I thought you wanted to put only metacello in git.
| > |
| > | Do you mean that you would version method as git objects and use
| > | the
| > | git ancestry management to merge?
| > |
|
|