On Feb 13, 2004, at 6:16 PM, Avi Bryant wrote:

> I'm not sure I agree.  I would definitely want to at least save the 
> information about the specific dependencies - otherwise there's no way 
> to roll the whole thing back to a particular state ("what was Bert 
> thinking when he wrote this code?  Oh, I see, it's because he was 
> working against *that* version of this other package...").  I haven't 
> thought this through, but maybe one way to do it would be to record 
> dependencies in both directions?  So, if I make a major change to when 
> going from B3D-Morphic ar.32 to avi.33, which lets me totally 
> reorganize B3D-Kernel, when I save B3D-Kernel-avi.33, it will know 
> that it was saved with B3D-Morphic-avi.33 dependent on it.  Then when 
> I load B3D-Morphic-ar.32, it'll look at B3D-Kernel-avi.33, see the 
> reverse dependency, and decide this is too new for it.  On the other 
> hand if Bert meanwhile produces B3D-Kernel-bf.33, without even having 
> B3D-Morphic loaded (or having ar.32 loaded), it won't have that 
> particular reverse dependency, and so B3D-Morphic-ar.32 will be ok 
> with using it.

This wasn't very clear.  Let me try again:

- When you save a new version of a package, it records the current 
versions of any dependents (packages that depend on it) that it knows 
about (there may be some that are not currently loaded).  It also 
records the current versions of all of its dependencies.
- When you load version N of  package A, it will go through the 
packages named in its dependencies, and look for the latest version 
that has version N as a dependent (let us call this version X of 
package B).  Any versions of B later than X that have a version of A > 
N as a dependent will be ignored.  If there is any version of B later 
than X that does not have any version of A as a dependent (it was saved 
when A was not loaded), the user will be asked if they would prefer to 
use that one.  Failing any such version X it will look for the exact 
version specified in version N's dependency list.

One problem with this scheme is that currently there is only minimal 
metadata available from remote repositories (the filename).  This works 
if you're looking for a specific version but is no good when doing 
searches like this.  We need to fix this, pronto, either by introducing 
a metadata protocol that smart repositories like SqueakSource 
understand, or by treating repositories as feeds into a local cache and 
downloading everything in them at regular intervals.