Support for merging

[Adrian Lienhard]

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

[Miguel Enrique Cobá Martinez]

But I don't think that that is the intended use of Metacello. Metacello
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

[Mariano Martinez Peck]

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. 
 

Cheers

Mariano

[Dale Henrichs]

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" <adrian....@gmail.com> 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

[Adrian Lienhard]

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 

[Dale Henrichs]

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...