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
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@hotmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: squeak-dev@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 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=...
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
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@hotmail.com Reply-To: The general-purpose Squeak developers list<squeak- dev@lists.squeakfoundation.org> To: squeak-dev@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
And RB does not always record changes.
Cheers Philippe
2007/4/28, stephane ducasse stephane.ducasse@free.fr:
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@hotmail.com Reply-To: The general-purpose Squeak developers list<squeak- dev@lists.squeakfoundation.org> To: squeak-dev@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
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; tim@rowledge.org; http://www.rowledge.org/tim Computing Dictionary: Recursive: (see Recursive)
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 stephane.ducasse@free.fr Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org 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" azreal1977@hotmail.com Reply-To: The general-purpose Squeak developers list<squeak- dev@lists.squeakfoundation.org> To: squeak-dev@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 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=1...
squeak-dev@lists.squeakfoundation.org
-
Colin Putney -
J J -
Philippe Marschall -
stephane ducasse -
tim Rowledge