Monticello 2 question (sort of)

stephane ducasse stephane.ducasse at free.fr
Sat Apr 28 19:54:18 UTC 2007


Just a remark yu may have noticed (in that case do not care of my  
remarks)
that changeset do not record the changes themselves but the fact that  
something changed.
You cannot have two versions of the same method in different cs  
loaded in the image.


On 27 avr. 07, at 21:24, J J wrote:

> 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=40 
> 56&p=5117
>
>
>




More information about the Squeak-dev mailing list