To override repositories one uses this expression:

  | version |
  version := ConfigurationOfGLASS project version: '1.0-beta.2'.
  version versionSpec loader repositoryOverrides: <list of MC repositories>.
  version load: 'Seaside3.0 Dev'.

That's not very obvious...

should pull the #repositoryOverrides up to version.

see
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-November/015820.html
for context

see http://groups.google.com/group/metacello/msg/49160264aae4ac88

http://groups.google.com/group/metacello/browse_frm/thread/2e25a698f68683f8/e9e1
6508853d6799#e9e16508853d6799

When loading packages, #linear is never wrong ... as long at the required
packages are defined correctly and the packages are formed correctly. 

#atomic loading is most useful for updating (in the case where methods are
moved between packages), but it can also be useful when there is a bit of
incest between packages ...

Both of those cases can be considered as a special case.

The current version cache should be a dynamic cache rather than a static
cache ...

See
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-December/017082.html
for thread ...

Sending #fetch (or something) to a version wshould result in a fetch being
done on each repository...Note that #fetch is still under development by
Lukas...

----- "stephane ducasse" <[email protected]> wrote:

| - for save paackages: why do you only look at dirty packages (in  
| scriptLoader we have to pay attention that you can get a new version
|
| that is not dirty
|       so we collect dirty and new version of packages).
|
|       update package methods -> update package metadata? 

The current date attribute is a string. The current format is

MM/DD/YYYY HH:MM

that is U.S. centric.

It should be standardized to a common date format, e.g. the SQL date format:

YYYY-MM-DD HH:MM

so that december 3rd can be understood by everyone in the world.

Current: 12/03/2009
is that December 3rd or March 12th?

Proposed: 2009-12-03.

Or maybe some ISO or ANSI format that have not ambiguities.

Thanks

I find that when I'm using #development blessing, I'm updating the version
on a regular basis, but of course it isn't desirable to snap off a version
every time, but it would be interesting to have a build counter that could
be displayed so that folks have a chance to figure out if things have
changed or not, just by looking at a version string ... 

not sure if I want the official version name to have a build number...but
sometimes it's convenient ...

If you explicitly load 1.0-beta.2 from the ;Load Version' menu. the
'Current Version' command reports '~1.0beta.0' as the current version.

As a side effect `MetacelloConfiguration loadTools` doesn't do the expected
thing

I would need to have preDoIts and postDoIts for a complete
ConfigurationOfXXX not only per package.

For more information read the thread with subject: "Questions about Metacello"

In addition maybe it make sense to: 
1) Or put a validation so that the argument is a selector
2) Support to receive a block or a selector. Or just block. 

I need this in several Configurations, included GlorpDBX and Pharo. 

Thanks

the online tutorial is a duplication of the code-based tutorial and is
currently unfinished ... 

It is worth validating that the pattern used for the existing tutorial
makes sense and then it's just a matter of finishing off the missing lessons.

Stef brought up the original issue:

- When you specify a list for repositories is it not dangerous since  
MC does not inforce
unique number accross repositories? 

Then Julian chimed in:

Don't MC packages have a UUID though? Maybe you should support
specifying that as well? 

See Pharo Issue 1522 (http://code.google.com/p/pharo/issues/detail?id=1522)
for description of problem and a workaround...

for discussion see:


http://groups.google.com/group/metacello/browse_thread/thread/d77754e5bd059e40#

See for detailed instructions on reproducing:
  http://groups.google.com/group/metacello/browse_frm/thread/a21cfa51ff64eee0

I am suspicious that the boundary between #linear and #atomic loads are not
handled quite right, since there is no code currently reasoning about the
transitions ...

Ought to come up with the rules for transitions and enforce them...

see http://groups.google.com/group/metacello/browse_frm/thread/21b574485dcfa69e

What steps will reproduce the problem?

Downloaded 2.8.4 Pharo/Seaside one click image 
http://www.seaside.st/distributions/Seaside-2.8.4.app.zip

From Monticello loaded latest Metacello:

    Name: Seaside-Metacello-Configuration-dkh.17
    Author: dkh
    Time: 27 October 2009, 8:29:50 am
    UUID: fa933592-9047-4e63-b42c-e926fe58a925
    Ancestors: Seaside-Metacello-Configuration-dkh.16

    - missed Seaside-Pharo-Canvas first time around

From a workspace, ran: SeasideConfiguration loadLatestVersion

threw 'stream is already defined in a subclass of WAHtmlDocument'

What is the expected output? completed load
What do you see instead? walkback


What version of the product are you using? On what operating system?
seaside/pharo/metacello as above. Ubuntu 9.04

Cheers,   ...Stan

Please provide any additional information below.

Walkback attached

Hi Dale! What do you think about putting a project in the ensureMetacello ?    

I mean...I would like ensureMetacello do something like  
ConfigurationOfMetacello project lastVersion load
or something similar instead of ConfigurationOfMetacello project
lastVersion load
because with this way (as it is now) every time I want to load it in a
PharoCore image it warns me about the dependencies (ok, because I don't
have OB installed).

I would be cool if ensueMetacello only installs the "core".

What do you think? Maybe I am just the only want who rather this, so in
this case just ignore me :)

When hooking up a Monticello package with the repository in which it
resides, and its a file-based repository, add it as MCServerDirectory when
on GemStone.

Should automate the more complex steps, since it's even more of a pain to
do these things manually ...

Similar problems to Issue 10.

Makes sense to have pre/post doits at the project level

Makes sense to have pre/post doits at the project level

see discussion in first couple of messages in:

http://groups.google.com/group/metacello/browse_frm/thread/cf8239bba80da958?tvc=
1

Keep in mind that the 'final filter' needs to include both the version
pattern and blessing...

The fields should be included the versionspec

see discussion:
http://groups.google.com/group/metacello/browse_frm/thread/8ec2a917a436ca3c

MetacelloVersionQueryTestCase provides the most useful examples, but the
tutorial should be extended with the 'standard' examples...

With the fix for Issue 40, the Metacello repository lookup behavior shifted.

Prior to 1.0-beta.20, when a repository was specified on a package, the
version repositories were included in the lookup up list, so that the
package version could be found in another repository.

With 1.0-beta.20, when a repository (or list) is specified for a package,
only the version repositories are not used for lookup.

This is closer to the way I expect it to work and now that you can specify
multiple repositories for a package, there isn't a real limitation.

see
http://groups.google.com/group/metacello/browse_frm/thread/d7bb40c50d653440.

The idea would be that we'd answer a load report object that could answer
supply which projects/packages were loaded ... and the order that they were
loaded in ...

Just trying to create a version is enough to start with ... since that
reveals most of the errors...

see http://groups.google.com/group/metacello/browse_frm/thread/cf06a9806f1e378b

see
http://groups.google.com/group/metacello/browse_frm/thread/f52d9f8469e555fd# for
discussion

the title says it all

when no #common attribute is used in a version, the author and timestamp
fields aren't updated ... think about specifying author and timestamp for
each attribute...

see discussion:
http://groups.google.com/group/metacello/browse_frm/thread/13228acd1994754d

With the work on Issue 40, #versionInfoFor:from:do: is really no longer
needed. GoferPackages of one form or another can be used to look up and
repositories and versionInfo information. Gofer does commits (and copies?)
so that just about all uses of #versionInfoFor:from:do: and friends can be
eliminated. 

They aren't on the mainline path, so it is less of a priority to get rid of
them.

Any shadowing across project/package/group boundaries is not cool...will
result in error sooner or later, but could be hard to figure out without
explicit error condition

See http://groups.google.com/group/metacello/msg/7bbc7a5338e73bfb.

Just need to add a load that loads the core and we'd be done!

see
http://groups.google.com/group/metacello/browse_frm/thread/28716edbdae40612# for
discussion

See
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-December/017709.html
for the request and rationale...

see http://groups.google.com/group/metacello/msg/8f651057c03fe958 for
original request from Simon

You should be able to start at a top-level configuration and get all of the
packages saved, even updating the package methods and saving the projects
all in one step ... at least that's the theory...don't want a whole lot of
prompting going on, but some level of prompting will be necessary ... gofer
does mass commits so look at what it does, too...

Mariano noticed a problem with loading an older version of OB even though
the later version should have been current:

  http://groups.google.com/group/metacello/browse_frm/thread/e8a08b3ed1a9b772#

During some of my own testing of configs, I was able to reproduce the
problem and tracked it down to the fact that #findCurrentVersion expects
all of the packages for a project to be loaded and current. Therefore for a
project that was already partially loaded, a load of the older project is
done ... I'm now putting together a test case for the problem

From Doru (http://groups.google.com/group/metacello/msg/baf697441def95f0):

Gofer has changed significantly, and it looks like it breaks metacello.

In particular, MetacelloGoferPackage inherits from GoferReference  
which does not understand setName: and setRepository: anymore.

Now that OB has configurations, the Metacello tools should be made
dependent upon upon that configuration.

See http://groups.google.com/group/metacello/msg/4480c6c7c1e6cda3

It's easy to pass a block into these methods which is not correct ...
perhaps the methods should be renamed to:

  #postLoadDoItSelector:/#preLoadDoitSelector:

see http://groups.google.com/group/metacello/browse_frm/thread/9c53bae02f6cb5ae

Useful meta data for cataloging.

This info can be added during project creation ... not conditional

What steps will reproduce the problem?
1. Fire up current Squeak trunk image.
2. Load a configuration (I used ConfigurationOfFFI)

Loading Metacello fails in the middle with some OB dependencies. 
It would be good if the loading of the OB parts could be made optional,
Squeak has by default OB not loaded and it'd be a sizable requirement.