On Feb 13, 2004, at 6:01 PM, Andreas Raab wrote:

> For dependencies I would probably opt for having a "release commit" 
> which
> really freezes the particular dependencies. So if I do a release commit
> against Balloon3D-All-main.42 then it would depend on, say,
> Balloon-Kernel-main.22 and Balloon-Constants-main.2 whereas for a 
> "regular
> commit" it would merely say that Balloon3D-All-main.43 depends on
> Balloon-main.* and Balloon-Constants-main.*

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

> Oh, and two more things: When dependent packages are loaded, the 
> associated
> repository isn't available in the MC browser. E.g., if you load
> Balloon3D-All the repository for the other packages seems to be lost.

Ok, thanks.

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

Avi