So, I guess this was a dumb question?

I am curious because I was considering testing some code myself to make a 
current generation change management system based on the change set 
mechanism that Squeak already has.  But if Monticello 2 is already going to 
do this then I'll just wait and focus on other things.


>From: "J J" <azreal1977 at hotmail.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: squeak-dev at lists.squeakfoundation.org
>Subject: Monticello 2 question (sort of)
>Date: Tue, 24 Apr 2007 04:43:10 +0000
>
>Hi all,
>
>I was just thinking about Monticello 2 and wondering what the strategy for 
>creating revisions is.
>
>In darcs (and afaik all modern revision systems) the way it works is, I 
>have a local repository and there can be any number of remote repositories. 
>  So if we had one central repository called e.g. SqueakSource, after the 
>initial push, my local repository is in sync with SqueakSource.  I can now 
>make changes and publish them locally.  If I push these changes to the 
>SqueakSource repository all the system has to do is see if the revision has 
>not changed, and if it hasn't apply all my change sets to get back in sync 
>and so on.
>
>It strikes me that Squeak can do this very easily.  We already have change 
>sets that actually seem very good.  So we could do the same thing; when I 
>do an initial publish to the central repository I am in sync.  Now the 
>system creates a new change set for all changes I do from this point 
>forward.  Later on when I try to sync again, if the version number has not 
>changed the system need only apply the change sets I have made since the 
>sync took place.  If the version number has changed, a simple conflict 
>resolution can be done.
>
>The key point here is; it looks to me like the current Monticello is 
>actually scanning the whole image to find out what has changed.  This is 
>not necessary as all that information and more can be retrieved via the 
>existing change set mechanism.  The only change would need to be that after 
>you publish to a repository, Monticello needs to rename your "current" 
>change set.  If it doesn't then the next time you publish it wont see any 
>change sets that aren't present in the repository and decide no work was 
>done.  Or it can look if the dates are different, but then it would have to 
>scan the whole change set to see what is different.  It saves processing by 
>simply controlling the change set names.
>
>Another advantage is, we can easily have the darcs ability to only apply 
>certain change sets.  Using the change set tools in the image I can create 
>new change sets and push different changes into those, so that if I made a 
>big change I can split it up into several different change sets.  Then I 
>would have the ability to say e.g. only publish the first one and the last, 
>but skip the middle.
>
>What do you all think?  Is this already what it's doing and I just didn't 
>notice?  Thoughts?
>
>Thanks,
>Jason
>
>_________________________________________________________________
>Download Messenger. Join the i’m Initiative. Help make a difference today. 
>http://im.live.com/messenger/im/home/?source=TAGHM_APR07
>
>

_________________________________________________________________
Mortgage rates near historic lows. Refinance $200,000 loan for as low as 
$771/month* 
https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h27f8&disc=y&vers=689&s=4056&p=5117