Support for merging
Locked
 
|
Hi all,
I'd like to consider switching to Metacello to replace a combination of MC packages with dependencies and MC configuration maps that we use now at Cmsbox and netstyle.ch.
Looking through the supported actions of Metacello I cannot figure out how to *merge* two configuration versions (merging the meta data is ok through MC, but that does not help merging package versions that were concurrently modified). I wonder whether I miss something or if Metacello does not (yet) support this scenario (i.e., being a source code management system for everyday development with multiple people)?
Cheers, Adrian
|
|
|
El jue, 11-03-2010 a las 16:29 +0100, Adrian Lienhard escribió:
> Hi all, > > > I'd like to consider switching to Metacello to replace a combination > of MC packages with dependencies and MC configuration maps that we use > now at Cmsbox and netstyle.ch. > > > Looking through the supported actions of Metacello I cannot figure out > how to *merge* two configuration versions (merging the meta data is ok > through MC, but that does not help merging package versions that were > concurrently modified). I wonder whether I miss something or if > Metacello does not (yet) support this scenario (i.e., being a source > code management system for everyday development with multiple people)? > > as I use it, and I think is meant to be used is as a medium to release finished/released/beta versions of a package. That set of individual MC packages that conform a given version is what correspond to a Metacello version. In this context, one person would be in charge of building the official release of you packages by using a set of monticello packages that he knows that work "correctly" together and other people can use. BTW, a Metacello config is a monticello package with just a class. So the merging tools of Monticello can be used to merge methods changed in the case that two persons modified the same method. But as I said, I think that this isn't the way to use Metacello IMHO. Cheers > Cheers, > Adrian -- Miguel Cobá http://miguel.leugim.com.mx |
Re: Support for merging
|
|
BTW, a Metacello config is a monticello package with just a class. Yes, but not necesary ;) We are doing that for MonticelloRepository but it is not strictly imposed by Metacello. Mariano |
|
|
In reply to this post by Adrian Lienhard-3
Adrian,
I have been thinking about merge/merge: as a command for Metacello for awhile now. A week ago I would have said that we'd need to create a spec loader class that did merges instead of loads and we'd be good to go ... I'm a bit on the fence when it comes to the field of developer support ... not from the perspective of "metacello shouldn't be used from that" but from the perspective of wanting to maintain a clean separation between metacello and tools. As of the current release (1.0-beta.24), I wouldn't say there is a clean separation (ask Doru and Simon:), but my recent work with fetch/fetch: has yielded some nice results that should make building tools on top of Metacello, much easier. If you read my recent mail on fetch/fetch: (see http://groups.google.com/group/metacello/msg/87e1c9d5017d2f34), you'll see that I split the load process up into a fetch phase and load phase. Since sending that mail, I've changed the structure of a load even more. The fetch/fetch: pass now builds a "load directive" structure that includes information about each package and configuration involved in the "load". So when the following expression is printed: ((ConfigurationOfSeaside project version: '1.0.3') fetch: #('Seaside 2.8' 'Magritte Tests')) loadDirective. You get something that looks like this: linear load : linear load : 1.0.3 [ConfigurationOfSeaside] linear load : 1.0.3 [ConfigurationOfSeaside] linear load : 1.0.3 [ConfigurationOfSeaside] linear load : 1.2.1.4 [ConfigurationOfMagritte] linear load : 1.2.1.4 [ConfigurationOfMagritte] linear load : 2.8.4.2 [ConfigurationOfSeaside28] linear load : 2.8.4.2 [ConfigurationOfSeaside28] linear load : 1.0 [ConfigurationOfKomHttpServer] load : DynamicBindings-lr.11 load : KomServices-gc.19 load : KomHttpServer-lr.51 load : Seaside2.8a1-pmm.596 load : RSRSS2-pmm.12 load : Scriptaculous-lr.250 load : Comet-lr.29 load : Magritte-Model-lr.367 load : Magritte-Seaside-lr.316 load : Magritte-Tests-lr.159 load : Magritte-Morph-jmck.49 linear load : 2.8.4.4 [ConfigurationOfSeaside28] linear load : 1.0.1 [ConfigurationOfKomHttpServer] load : DynamicBindings-ul.12 The load directives hold onto packageSpecs (including configuration packages) and repositories (both the metacello cache and the "original repository") so all of the information you need to do a merge can be accessed from the load directive structure. If you send #load to the load directive, the packages will be loaded ... there is no "load pass." You can also do record/record: which just records packageSpecs involved without doing any fetching either ... making it possible to reason about the structure of the load without having to hit the web... I plan to reimplement #savePackages using loadDirectives...my expectation is that tools for Metacello will be much easier to write... Just for fun, here's the load directive for Seaside3.0: ((ConfigurationOfSeaside project version: '1.0.3') record: #('Seaside 3.0' 'Magritte2 Tests')) loadDirective. linear load : linear load : 1.0.3 [ConfigurationOfSeaside] load : ConfigurationOfSeaside30 linear load : 1.0.3 [ConfigurationOfSeaside] load : ConfigurationOfMagritte2 linear load : 1.0.3 [ConfigurationOfSeaside] linear load : 2.0.2 [ConfigurationOfMagritte2] load : ConfigurationOfGrease linear load : 2.0.2 [ConfigurationOfMagritte2] load : ConfigurationOfSeaside30 linear load : 2.0.2 [ConfigurationOfMagritte2] linear load : 1.0-alpha6 [ConfigurationOfGrease] load : Grease-Core-obi.30 load : Grease-Pharo-Core-pmm.13 linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] load : ConfigurationOfOmniBrowser linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] load : ConfigurationOfSPort2 linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] load : ConfigurationOfKomHttpServer linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] load : ConfigurationOfGrease linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] load : ConfigurationOfSwazoo2 linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] linear load : 1.0-alpha6 [ConfigurationOfGrease] linear load : 1.1 [ConfigurationOfRefactoringBrowser] load : AST-Core-lr.49 load : AST-Tests-lr.5 load : Refactoring-Core-lr.101 load : Refactoring-Tests-lr.31 load : Refactoring-Spelling-lr.18 load : Grease-Slime-lr.3 load : Seaside-Pharo-Continuation-lr.5 linear load : 2.2.0.2 [ConfigurationOfSwazoo2] load : ConfigurationOfSPort2 linear load : 2.2.0.2 [ConfigurationOfSwazoo2] linear load : 2.31 [ConfigurationOfSPort2] load : Sport-2.031 load : Swazoo-lr.3 load : Seaside-Core-lr.625 load : Seaside-Pharo-Core-lr.5 load : Seaside-Component-lr.82 load : Seaside-Canvas-lr.94 load : RSS-Core-lr.59 load : Javascript-Core-lr.83 load : Javascript-Pharo-Core-lr.7 load : Prototype-Core-lr.19 load : Scriptaculous-Core-lr.96 load : JQuery-Core-lr.103 load : JQuery-UI-lr.52 load : Seaside-Email-lr.15 load : Seaside-Pharo-Email-lr.6 load : Seaside-HTML5-lr.9 load : Seaside-InternetExplorer-lr.6 load : Seaside-Session-jf.130 load : Seaside-RenderLoop-lr.72 load : Seaside-Tools-Core-lr.17 load : Seaside-Flow-lr.21 load : Seaside-Pharo-Flow-lr.5 load : Seaside-Examples-lr.17 load : RSS-Examples-lr.24 load : Seaside-Widgets-lr.16 load : Seaside-Tools-Web-lr.78 load : Seaside-Development-lr.133 load : Seaside-Environment-lr.69 load : Scriptaculous-Components-lr.99 load : Seaside-Swazoo-jf.19 load : Seaside-Adaptors-Swazoo-lr.36 linear load : 1.0.1 [ConfigurationOfKomHttpServer] load : DynamicBindings-ul.12 load : KomServices-gc.19 load : KomHttpServer-lr.51 linear load : 1.1 [ConfigurationOfOmniBrowser] load : ConfigurationOfOCompletion linear load : 1.1 [ConfigurationOfOmniBrowser] linear load : 1.1 [ConfigurationOfOCompletion] load : ConfigurationOfShout linear load : 1.1 [ConfigurationOfOCompletion] linear load : 1.0 [ConfigurationOfShout] load : Shout-nice.83 load : ShoutWorkspace.1-tween.4 load : ShoutTests-tween.9 load : RoelTyper-DamienCassou.80 load : Ocompletion-RomainRobbes.52 load : OcompletionTests-MarianoMartinezPeck.3 load : OmniBrowser-lr.458 load : OB-Morphic-lr.112 load : OB-Standard-lr.442 load : OB-SUnitIntegration-lr.22 load : OB-Shout-cwp.2 load : OB-Refactory-lr.194 load : OB-Regex-lr.21 load : OB-Tests-Core-lr.77 load : OB-Tests-Morphic-lr.23 load : BogusInfo-lr.18 load : OB-Fake-lr.12 load : OB-Tests-Standard-lr.100 load : OCForOB-rr.2 load : Seaside-Tools-OmniBrowser-lr.14 load : Seaside-Pharo-Canvas-lr.3 load : Seaside-Pharo-Environment-lr.6 load : Seaside-Pharo-Tools-Web-lr.21 load : Seaside-Pharo-Development-lr.39 load : Seaside-Pharo-Tools-OmniBrowser-lr.5 load : Seaside-Adaptors-Comanche-lr.55 load : Comet-Core-lr.49 load : Comet-Pharo-Core-lr.6 load : Comet-Examples-lr.17 load : Seaside-FileSystem-lr.23 load : Seaside-Slime-lr.77 load : Magritte-Model-lr.394 load : Magritte-Morph-lr.51 load : Magritte-Pharo-Model-lr.22 load : Magritte-Tests-Model-lr.12 load : Magritte-Seaside-lr.333 load : Magritte-Tests-Pharo-Model-lr.4 load : Magritte-Pharo-Seaside-lr.5 linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] Dale ----- "Adrian Lienhard" <[hidden email]> wrote: | Hi all, | | I'd like to consider switching to Metacello to replace a combination | of MC | packages with dependencies and MC configuration maps that we use now | at | Cmsbox and netstyle.ch. | | Looking through the supported actions of Metacello I cannot figure out | how | to *merge* two configuration versions (merging the meta data is ok | through | MC, but that does not help merging package versions that were | concurrently | modified). I wonder whether I miss something or if Metacello does not | (yet) | support this scenario (i.e., being a source code management system | for | everyday development with multiple people)? | | Cheers, | Adrian |
|
|
Hi Dale,
Thanks for the info. It seems that Metacello has most of the pieces that MC lack to properly support source management in the development process. The main problem we have with MC is that as soon as a project consists of many packages from different repositories it gets cumbersome to save, load, and merge code because a MC package does not know the repository it belongs to. A Metacello spec provides exactly this information. I'm aware that merging is not a main use case of Metacello but maybe a worthwhile extension...
Cheers, Adrian
On Thu, Mar 11, 2010 at 8:35 PM, Dale Henrichs <[hidden email]> wrote: Adrian, |
|
|
Adrian,
As the the thoughts about merging "marinated" over the weekend ... I think that merge _is_ on a par with load ... given that Gofer supports merge, a first order cut shouldn't be too hard to add ... I am getting close to releasing 1.0-beta.25 (which won't include merge:) as I'm trying to push out a version of GLASS ... once GLASS is pushed out I plan on finishing up 1.0 for metacello (release candidate) and merge will make it in if it is as strarightforward as I think it is... Dale ----- "Adrian Lienhard" <[hidden email]> wrote: | Hi Dale, | | Thanks for the info. It seems that Metacello has most of the pieces | that MC | lack to properly support source management in the development process. | The | main problem we have with MC is that as soon as a project consists of | many | packages from different repositories it gets cumbersome to save, load, | and | merge code because a MC package does not know the repository it | belongs to. | A Metacello spec provides exactly this information. I'm aware that | merging | is not a main use case of Metacello but maybe a worthwhile | extension... | | Cheers, | Adrian | | On Thu, Mar 11, 2010 at 8:35 PM, Dale Henrichs | <[hidden email]>wrote: | | > Adrian, | > | > I have been thinking about merge/merge: as a command for Metacello | for | > awhile now. A week ago I would have said that we'd need to create a | spec | > loader class that did merges instead of loads and we'd be good to go | ... | > | > I'm a bit on the fence when it comes to the field of developer | support ... | > not from the perspective of "metacello shouldn't be used from that" | but from | > the perspective of wanting to maintain a clean separation between | metacello | > and tools. As of the current release (1.0-beta.24), I wouldn't say | there is | > a clean separation (ask Doru and Simon:), but my recent work with | > fetch/fetch: has yielded some nice results that should make building | tools | > on top of Metacello, much easier. | > | > If you read my recent mail on fetch/fetch: (see | > http://groups.google.com/group/metacello/msg/87e1c9d5017d2f34), | you'll see | > that I split the load process up into a fetch phase and load phase. | > | > Since sending that mail, I've changed the structure of a load even | more. | > | > The fetch/fetch: pass now builds a "load directive" structure that | includes | > information about each package and configuration involved in the | "load". So | > when the following expression is printed: | > | > ((ConfigurationOfSeaside project version: '1.0.3') | > fetch: #('Seaside 2.8' 'Magritte Tests')) loadDirective. | > | > You get something that looks like this: | > | > linear load : | > linear load : 1.0.3 [ConfigurationOfSeaside] | > linear load : 1.0.3 [ConfigurationOfSeaside] | > linear load : 1.0.3 [ConfigurationOfSeaside] | > linear load : 1.2.1.4 [ConfigurationOfMagritte] | > linear load : 1.2.1.4 [ConfigurationOfMagritte] | > linear load : 2.8.4.2 [ConfigurationOfSeaside28] | > linear load : 2.8.4.2 [ConfigurationOfSeaside28] | > linear load : 1.0 [ConfigurationOfKomHttpServer] | > load : DynamicBindings-lr.11 | > load : KomServices-gc.19 | > load : KomHttpServer-lr.51 | > load : Seaside2.8a1-pmm.596 | > load : RSRSS2-pmm.12 | > load : Scriptaculous-lr.250 | > load : Comet-lr.29 | > load : Magritte-Model-lr.367 | > load : Magritte-Seaside-lr.316 | > load : Magritte-Tests-lr.159 | > load : Magritte-Morph-jmck.49 | > linear load : 2.8.4.4 [ConfigurationOfSeaside28] | > linear load : 1.0.1 [ConfigurationOfKomHttpServer] | > load : DynamicBindings-ul.12 | > | > The load directives hold onto packageSpecs (including configuration | > packages) and repositories (both the metacello cache and the | "original | > repository") so all of the information you need to do a merge can | be | > accessed from the load directive structure. | > | > If you send #load to the load directive, the packages will be loaded | ... | > there is no "load pass." | > | > You can also do record/record: which just records packageSpecs | involved | > without doing any fetching either ... making it possible to reason | about the | > structure of the load without having to hit the web... | > | > I plan to reimplement #savePackages using loadDirectives...my | expectation | > is that tools for Metacello will be much easier to write... | > | > Just for fun, here's the load directive for Seaside3.0: | > | > ((ConfigurationOfSeaside project version: '1.0.3') | > record: #('Seaside 3.0' 'Magritte2 Tests')) loadDirective. | > | > linear load : | > linear load : 1.0.3 [ConfigurationOfSeaside] | > load : ConfigurationOfSeaside30 | > linear load : 1.0.3 [ConfigurationOfSeaside] | > load : ConfigurationOfMagritte2 | > linear load : 1.0.3 [ConfigurationOfSeaside] | > linear load : 2.0.2 [ConfigurationOfMagritte2] | > load : ConfigurationOfGrease | > linear load : 2.0.2 [ConfigurationOfMagritte2] | > load : ConfigurationOfSeaside30 | > linear load : 2.0.2 [ConfigurationOfMagritte2] | > linear load : 1.0-alpha6 [ConfigurationOfGrease] | > load : Grease-Core-obi.30 | > load : Grease-Pharo-Core-pmm.13 | > linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] | > load : ConfigurationOfOmniBrowser | > linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] | > load : ConfigurationOfSPort2 | > linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] | > load : ConfigurationOfKomHttpServer | > linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] | > load : ConfigurationOfGrease | > linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] | > load : ConfigurationOfSwazoo2 | > linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] | > linear load : 1.0-alpha6 [ConfigurationOfGrease] | > linear load : 1.1 [ConfigurationOfRefactoringBrowser] | > load : AST-Core-lr.49 | > load : AST-Tests-lr.5 | > load : Refactoring-Core-lr.101 | > load : Refactoring-Tests-lr.31 | > load : Refactoring-Spelling-lr.18 | > load : Grease-Slime-lr.3 | > load : Seaside-Pharo-Continuation-lr.5 | > linear load : 2.2.0.2 [ConfigurationOfSwazoo2] | > load : ConfigurationOfSPort2 | > linear load : 2.2.0.2 [ConfigurationOfSwazoo2] | > linear load : 2.31 [ConfigurationOfSPort2] | > load : Sport-2.031 | > load : Swazoo-lr.3 | > load : Seaside-Core-lr.625 | > load : Seaside-Pharo-Core-lr.5 | > load : Seaside-Component-lr.82 | > load : Seaside-Canvas-lr.94 | > load : RSS-Core-lr.59 | > load : Javascript-Core-lr.83 | > load : Javascript-Pharo-Core-lr.7 | > load : Prototype-Core-lr.19 | > load : Scriptaculous-Core-lr.96 | > load : JQuery-Core-lr.103 | > load : JQuery-UI-lr.52 | > load : Seaside-Email-lr.15 | > load : Seaside-Pharo-Email-lr.6 | > load : Seaside-HTML5-lr.9 | > load : Seaside-InternetExplorer-lr.6 | > load : Seaside-Session-jf.130 | > load : Seaside-RenderLoop-lr.72 | > load : Seaside-Tools-Core-lr.17 | > load : Seaside-Flow-lr.21 | > load : Seaside-Pharo-Flow-lr.5 | > load : Seaside-Examples-lr.17 | > load : RSS-Examples-lr.24 | > load : Seaside-Widgets-lr.16 | > load : Seaside-Tools-Web-lr.78 | > load : Seaside-Development-lr.133 | > load : Seaside-Environment-lr.69 | > load : Scriptaculous-Components-lr.99 | > load : Seaside-Swazoo-jf.19 | > load : Seaside-Adaptors-Swazoo-lr.36 | > linear load : 1.0.1 [ConfigurationOfKomHttpServer] | > load : DynamicBindings-ul.12 | > load : KomServices-gc.19 | > load : KomHttpServer-lr.51 | > linear load : 1.1 [ConfigurationOfOmniBrowser] | > load : ConfigurationOfOCompletion | > linear load : 1.1 [ConfigurationOfOmniBrowser] | > linear load : 1.1 [ConfigurationOfOCompletion] | > load : ConfigurationOfShout | > linear load : 1.1 [ConfigurationOfOCompletion] | > linear load : 1.0 [ConfigurationOfShout] | > load : Shout-nice.83 | > load : ShoutWorkspace.1-tween.4 | > load : ShoutTests-tween.9 | > load : RoelTyper-DamienCassou.80 | > load : Ocompletion-RomainRobbes.52 | > load : OcompletionTests-MarianoMartinezPeck.3 | > load : OmniBrowser-lr.458 | > load : OB-Morphic-lr.112 | > load : OB-Standard-lr.442 | > load : OB-SUnitIntegration-lr.22 | > load : OB-Shout-cwp.2 | > load : OB-Refactory-lr.194 | > load : OB-Regex-lr.21 | > load : OB-Tests-Core-lr.77 | > load : OB-Tests-Morphic-lr.23 | > load : BogusInfo-lr.18 | > load : OB-Fake-lr.12 | > load : OB-Tests-Standard-lr.100 | > load : OCForOB-rr.2 | > load : Seaside-Tools-OmniBrowser-lr.14 | > load : Seaside-Pharo-Canvas-lr.3 | > load : Seaside-Pharo-Environment-lr.6 | > load : Seaside-Pharo-Tools-Web-lr.21 | > load : Seaside-Pharo-Development-lr.39 | > load : Seaside-Pharo-Tools-OmniBrowser-lr.5 | > load : Seaside-Adaptors-Comanche-lr.55 | > load : Comet-Core-lr.49 | > load : Comet-Pharo-Core-lr.6 | > load : Comet-Examples-lr.17 | > load : Seaside-FileSystem-lr.23 | > load : Seaside-Slime-lr.77 | > load : Magritte-Model-lr.394 | > load : Magritte-Morph-lr.51 | > load : Magritte-Pharo-Model-lr.22 | > load : Magritte-Tests-Model-lr.12 | > load : Magritte-Seaside-lr.333 | > load : Magritte-Tests-Pharo-Model-lr.4 | > load : Magritte-Pharo-Seaside-lr.5 | > linear load : 3.0.0-alpha5.9 [ConfigurationOfSeaside30] | > | > Dale | > ----- "Adrian Lienhard" <[hidden email]> wrote: | > | > | Hi all, | > | | > | I'd like to consider switching to Metacello to replace a | combination | > | of MC | > | packages with dependencies and MC configuration maps that we use | now | > | at | > | Cmsbox and netstyle.ch. | > | | > | Looking through the supported actions of Metacello I cannot figure | out | > | how | > | to *merge* two configuration versions (merging the meta data is | ok | > | through | > | MC, but that does not help merging package versions that were | > | concurrently | > | modified). I wonder whether I miss something or if Metacello does | not | > | (yet) | > | support this scenario (i.e., being a source code management | system | > | for | > | everyday development with multiple people)? | > | | > | Cheers, | > | Adrian | > |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |