It's probably worth noting that this is also how people tend to use 
Store with VW.  Nested bundles become un-wieldy so people tend to use a 
single bundle that acts as a sort of versioned configuration (they have 
a defined load order).  People then tend to use scripts to grab the 
latest versions of packages in a bundle and that represents the tip 
development version.  To compare with Envy, this is like an open config 
map with an implicit release (i.e. when you publish a new version of a 
package, it is implicitly part of the tip version to the bundle).  It's 
still difficult to manage if you have multiple versions of a bundle that 
are under active and parallel development, but it's not terrible (you 
have to explicitly update and publish the branch configurations, which 
generates a lot of useless intermediate versions of the bundle).

Perhaps Monticello could use a couple different types of configurations:

- one where the config specifies exact package versions
- one where the config specifies only the package name and the latest 
version of a given package is always grabbed
- one that looks at other meta data associated with the package to 
determine which to load (such as the latest version with a given 
tag)...this could be used to better manage concurrent developement streams
- one that is completely pluggable with respect to the algorithm used to 
determine what version of a package is to be loaded (or these could just 
be new subclasses on an abstract config that people come up with)

Only the first type would be a concrete and unchangeable specification 
of exact packages and versions.  From the other types, you could 
generate a concreate config (a kind of snapshot of the state of a given 
config at a point in time).  Envy deals with this by having open 
editions (but you still must explicitly release things in an open 
edition).  I think you could get more mileage by separating these envy 
concepts (a version vs open edition) such that you can now have configs 
that are based on some version selection algorithm, and other configs 
that are an exact specification of package versions.

I agree that pre-requisites are not very useful beyond their 
documentation value (although, I think in the context of a modular 
system, pre-requisite specs would be useful...they would serve as a kind 
of declaration of required bindings that would need to be satisfied 
before a package could become operational).

- Stephen

Avi Bryant wrote:

>On Sun, 28 Nov 2004 14:15:15 +0100, Bert Freudenberg <bert at impara.de> wrote:
>
>  
>
>>Yes, we're using it now in a project of that size. MC is quite usable
>>now. You might want to make many smaller packages without dependencies,
>>otherwise merging is really slow, and you get a lot of useless versions
>>even though only the prerequisites changed. Instead, we just load the
>>newest version of each package, which works fine in a small team where
>>we can immediately sort out any problems.
>>    
>>
>
>Yes, that's how I work as well.  It's somewhat telling that the only
>packages I know of that use the dependency system extensively,
>OmniBrowser and Chuck, are essentially single-developer projects; for
>team use, I think my dependency implementation has failed.  It's an
>open question as to how to improve it, and patches are certainly
>welcome.  Speaking of which:
>
>  
>
>>I posted a couple of enhancements for supporting this style of work to
>>the MC list. In particular, packages are highlighted which have a newer
>>version available in the repository.
>>        http://mail.wiresong.ca/pipermail/monticello/2004-November/000112.html
>>    
>>
>
>Yeah, I'm sorry that I haven't gotten around to integrating these
>enhancements yet.  Real Soon Now ;).
>
>Avi
>
>  
>