Smalltalk › Squeak › Squeak - Dev

Monticello 2 question (sort of)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

J J-6

Monticello 2 question (sort of)

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 im Initiative. Help make a difference today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07

J J-6

RE: Monticello 2 question (sort of)

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" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: [hidden email]
>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 im 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

Colin Putney

Re: Monticello 2 question (sort of)

On Apr 27, 2007, at 12:24 PM, 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.

No, not a dumb question, just one that's difficult to answer.

Yes, darcs is interesting. Monticello2 came out of some discussions
that Avi and I had about the darcs versioning model. But Monticello2
uses a different model than darcs. In darcs, changes are grouped
together, and the dependencies between them are recorded so that when
a change is applied, all the changes it depends on can be applied as
well. In Monticello2, on the other hand, this history of each change
is recorded individually, so that they can be grouped and regrouped
arbitrarily.

The darcs model of recording dependencies is powerful, in that it can
give you better "coherence" when applying changes - if you make a lot
of small, inter-related changes to different parts of the code base,
darcs knows that they are related and keeps them together. This can
help avoid, for example, DNU errors because a merge applied a message
send, but not the method that implements it.

On the other hand, Monticello takes advantage of something that darcs
can't. Darcs has to deal with arbitrary text, while Monticello
operates at a higher level of abstraction - classes, methods,
variables etc. As a result, Monticello is able to decouple changes
from each other without introducing syntax errors. The end result is
that code versioned in Monticello can be organized in a variety of
ways - packages, change sets, or something else that we haven't
thought of yet.

So if you're interested in doing a darcs-like versioning system for
Squeak, don't let the (non) existence of Monticello2 stop you.

Colin

stephane ducasse

Re: Monticello 2 question (sort of)

In reply to this post by J J-6

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" <[hidden email]>
>> Reply-To: The general-purpose Squeak developers list<squeak-
>> [hidden email]>
>> To: [hidden email]
>> 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
>
>
>

Philippe Marschall

Re: Monticello 2 question (sort of)

And RB does not always record changes.

Cheers
Philippe

2007/4/28, stephane ducasse <[hidden email]>:

> 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" <[hidden email]>
> >> Reply-To: The general-purpose Squeak developers list<squeak-
> >> [hidden email]>
> >> To: [hidden email]
> >> 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
> >
> >
> >
>
>
>

timrowledge

Re: Monticello 2 question (sort of)

In reply to this post by stephane ducasse

On 28-Apr-07, at 12:54 PM, stephane ducasse wrote:

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

Last time I looked that was not quite true; the changesets keep a
copy of the actual method (which is one of the reasons images started
bloating until one did a cleanout of all old changesets) and if I
understood properly some code relating to Projects would swap
versions on entry and exit. Personally I do not like this state of
affairs much. I believe it was an attempt at some sort of project
based namespace that never got completed and - as is so often the
case - never got cleaned out. Perhaps now would be a good time to do it?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computing Dictionary: Recursive: (see Recursive)

J J-6

Re: Monticello 2 question (sort of)

In reply to this post by stephane ducasse

I read about that and it was my understanding that the change set actually
knows where the old code was, but the change sorter itself only ever shows
the current method. Is this incorrect?

>From: stephane ducasse <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Monticello 2 question (sort of)
>Date: Sat, 28 Apr 2007 21:54:18 +0200
>
>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" <[hidden email]>
>>>Reply-To: The general-purpose Squeak developers list<squeak-
>>>[hidden email]>
>>>To: [hidden email]
>>>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 im 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
>>
>>
>>
>
>

_________________________________________________________________
Interest Rates NEAR 39yr LOWS! $430,000 Mortgage for $1,299/mo - Calculate
new payment
http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-19132&moid=14888