[etoys-dev] Re: Merging Etoys

[David T. Lewis]

On Sat, Feb 20, 2010 at 09:16:36PM +0530, K. K. Subramaniam wrote:
> On Saturday 20 February 2010 04:56:30 pm Bert Freudenberg wrote:
> > What I meant to add is that this Etoys repo would hold all code currently
> > in the Etoys image, just as the trunk repo holds all code in the trunk
> > image. Ideally we'd add a configuration-based update mechanism just as in
> > trunk so that we can easily load updates by pushing a button. Does that
> > make the idea more clear?
> The source code in Etoys packages are less than 8% of overall source code (35k 
> out of 527k). Why not keep only the Etoys packages in the repo and compose an 
> image on demand from the current trunk? Patches for trunk could go into Inbox 
> while those for Etoys could go into tracker.
> 
> Is it possible to automatically harvest changesets in updates.list into mcz? 
> Then we don't have to decide between cs or mcz right away. I don't know the 
> history behind cs vs. mcz and don't intend to reawaken a flame war ;-).

Subbu,

It's not matter of one versus the other. Monticello is the right way to
commit updates and compare differences between packages, as Bert described.

In addition to this (not instead of), a list of change sets from an update
stream may be very useful for identifying when changes were made, who made
them, and for what reason.

>From my recent experience working on making MVC reloadable in trunk, I
can say that there were several times when I wished that I could find
an original change set to help me understand why something was done.
I suspect we will have similar situations as we work on Etoys in trunk,
so from my POV it would be ideal if we could use the Monticello
configuration that Bert described, and also have all of the change
sets available.

Dave