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

Good point. I don't mind recording the exact versions by the way - just
adhering to them ;-) So storing the precise version seems fine if you can
still signify somehow that you are more interested in the "up-to-date"
rather than this precise version (this probably makes more sense if there
are explicit branches).

> 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.  Does that make any sense

You are the expert ;-)

> > Secondly, mind to use a tree view instead of the current list for
> > dependencies?! ;-) It would be much easier to look at dependencies if
> > you
> > could just open the tree.
>
>
> >  Code is attached.
>
> My favorite three words...
>
> Although getting it as a .mcz would have made me even happier.  ;)

Sending a 230k zip to the list (which would be reject by the list admin
anyway) instead of a 5k uncompressed CS?! You gotta be kidding me ;-)

Cheers,
  - Andreas