Monticello dependency handling
Avi Bryant
avi at beta4.com
Sat Feb 14 02:16:25 UTC 2004
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
More information about the Squeak-dev
mailing list
|