Ok, good to know this works for someone other than Avi and I...
About the dialog: Actually, MCConfiguration>>upgrade shows the way. The relevant piece is:
[ver merge] on: MCMergeResolutionRequest do: [:request | request merger conflicts isEmpty ifTrue: [request resume: true] ifFalse: [request pass]]
We want ver to be the merger, instead of the version.
So I started to change MCConfigs to use a combination of the script and this element, but I went down a wrong path somewhere in there, don't think its worth continuing from.
Daniel
Marcus Denker wrote:
Am 27.09.2005 um 11:06 schrieb Avi Bryant:
On Sep 27, 2005, at 12:36 AM, stéphane ducasse wrote:
I think that this is normal that you did not got any problem anymore since everything was already loaded in the image I sent you. Now take a 93 image and load the script you did or load the script I did with all the packages (not only the modified ones) and you should get conflicts as I did (normally you will obtain the same image that the one I provided to you and this one report conflicts).
Nope. It worked just fine for me. Maybe it only works on this side of the Pacific.
Here's what I did:
- Start with the Squeak3.9a-6693.image
- Load Monticello-avi.274.mcz
- Run the script below
Then wait a really long time, hit Merge, wait a really long time again... and you're done.
Yes, worked for me, too.
The new packages are marked dirty, I think this is related to the fact that they don't have the 39a repository defined (they only have the local cache). So we need to somehow fix that.
How do we proceed? If we put a cs with Avi's code out into the update stream, the users would need to press the "merge" button. The question is if we want that...
Marcus
But markus I would like to have a script that contains ***ALL*** the squeak packages and not only the last ones that have been marked dirty.
This is why I included all the packages in my script. Can you try to do the same experience than me:
93 + MC274 + loading **all the packages**
Else I do not really see how we will be able to build a given version without having to create the previous ones.
Stef
On 27 sept. 05, at 20:02, Daniel Vainsencher wrote:
Ok, good to know this works for someone other than Avi and I...
About the dialog: Actually, MCConfiguration>>upgrade shows the way. The relevant piece is:
[ver merge] on: MCMergeResolutionRequest do: [:request | request merger conflicts isEmpty ifTrue: [request resume: true] ifFalse: [request pass]]
We want ver to be the merger, instead of the version.
So I started to change MCConfigs to use a combination of the script and this element, but I went down a wrong path somewhere in there, don't think its worth continuing from.
Daniel
Marcus Denker wrote:
Am 27.09.2005 um 11:06 schrieb Avi Bryant:
On Sep 27, 2005, at 12:36 AM, stéphane ducasse wrote:
I think that this is normal that you did not got any problem anymore since everything was already loaded in the image I sent you. Now take a 93 image and load the script you did or load the script I did with all the packages (not only the modified ones) and you should get conflicts as I did (normally you will obtain the same image that the one I provided to you and this one report conflicts).
Nope. It worked just fine for me. Maybe it only works on this side of the Pacific.
Here's what I did:
- Start with the Squeak3.9a-6693.image
- Load Monticello-avi.274.mcz
- Run the script below
Then wait a really long time, hit Merge, wait a really long time again... and you're done.
Yes, worked for me, too. The new packages are marked dirty, I think this is related to the fact that they don't have the 39a repository defined (they only have the local cache). So we need to somehow fix that. How do we proceed? If we put a cs with Avi's code out into the update stream, the users would need to press the "merge" button. The question is if we want that... Marcus
On Sep 27, 2005, at 11:56 PM, stéphane ducasse wrote:
But markus I would like to have a script that contains ***ALL*** the squeak packages and not only the last ones that have been marked dirty.
This is why I included all the packages in my script. Can you try to do the same experience than me:
93 + MC274 + loading **all the packages**
For what it's worth, that *is* what I did, and what Daniel did, and what Markus did...
Though if we're going to have scripts with all the packages like that, we should have some better optimizations in the merge code for the no-op cases.
Avi
Am 28.09.2005 um 08:56 schrieb stéphane ducasse:
But markus I would like to have a script that contains ***ALL*** the squeak packages and not only the last ones that have been marked dirty.
This is why I included all the packages in my script. Can you try to do the same experience than me:
93 + MC274 + loading **all the packages**Else I do not really see how we will be able to build a given version without having to create the previous ones.
I did not select dirty ones... I just did what avi did. And *only that*. No morphic splitters filein, no nothing.
I think your problem is that you re-do the morphic splitters filein. We all just used avi's script on the packages in the repository (as they are snapshots witht he splitters inluded).
A big question for me is: Can we somehow work in parallel, that is: 3.9 as released has some serious bugs that need to be adressed soon, but now we are stuck for 3 weeks. The problem is that I don't have too much time (e.g. to work on the MC merge thing), but merging in a couple of simple fixes in the old way would be no problem... I feel that we should not block simple stuff when working on making complex stuff possible.
Marcus
I did not select dirty ones... I just did what avi did. And *only that*. No morphic splitters filein, no nothing.
I think your problem is that you re-do the morphic splitters filein. We all just used avi's script on the packages in the repository (as they are snapshots witht he splitters inluded).
I did not filein the morphic splitters. I restarted to load the packages on 93. I'm not yet dead stupid!!!!
I loaded morphic spliiter to reproduce the package on my disc and not mess up the repository.
A big question for me is: Can we somehow work in parallel, that is: 3.9 as released has some serious bugs that need to be adressed soon, but now we are stuck for 3 weeks. The problem is that I don't have too much time (e.g. to work on the MC merge thing), but merging in a couple of simple fixes in the old way would be no problem... I feel that we should not block simple stuff when working on making complex stuff possible.
Marcus I think that this is important that we find a way to work fast even if this task takes some times.
I will try the script from the repository when I have a good bandwidth. I would like to version these scripts because we should be able to take a snapshot (that would only created because we could not do it otherwise) and recreate the latest image (put on the ftp only for making life easier).
Stef
So, what's stopping you from harvesting to the inbox repository, and then merge when this brouhaha is done?
Conflicts are likely to be small, especially so if you avoid Morphic stuff.
Parallelizable development and integration is pretty much the whole point of using MC, afaict...
Daniel
Marcus Denker wrote:
A big question for me is: Can we somehow work in parallel, that is: 3.9 as released has some serious bugs that need to be adressed soon, but now we are stuck for 3 weeks. The problem is that I don't have too much time (e.g. to work on the MC merge thing), but merging in a couple of simple fixes in the old way would be no problem... I feel that we should not block simple stuff when working on making complex stuff possible.
Marcus
Am 28.09.2005 um 19:48 schrieb Daniel Vainsencher:
So, what's stopping you from harvesting to the inbox repository, and then merge when this brouhaha is done?
Conflicts are likely to be small, especially so if you avoid Morphic stuff.
Parallelizable development and integration is pretty much the whole point of using MC, afaict...
Yes, it's a right observation that I need to get more into the MC mindset... but:
I don't think the direct process of harvesting is the most important part here, but getting an "official" image out there with the bugs fixed... having the fixes in the inbox in mc is not too different then having them in mantis, somehow... people who know that they need them could install them, but the image downloaded does not have them, nor do you see them when loading updates...
Marcus
I agree that there is some benefit that is gained only when a contribution makes it into the official streams, and therefore the continuity of the official stream does matter.
However, sometimes that has to be disturbed. Looking at another community, sometimes Linus goes on vacation. But the important thing is that when he gets back, he merges lots and lots of patches, because there's lots of patches that have been accumulating in a ready state in other peoples repositories.
So I think its important to figure out how to do everything that can be done outside the official stream to help the official stream work better. It used to be reviews and testing, and that worked to some extent (wasn't great). Now we have similar activities in Mantis, and I think that is insufficient in pretty much the same ways (not enough people doing it, because its too far outside Squeak, and there's no immediate benefit, and I think the email notifications aren't smart enough - needs something like roundup).
I think what we need is more people merging in other peoples stuff and putting the merged versions in public repositories. When someone bothers to merge something and put it out publically, they're probably telling you something quite meaningful about it. We still don't have a way to gather this feedback, but that wouldn't be hard (show all descendants of a version to see who is using some variation on it, and what variations exist).
Daniel
Marcus Denker wrote:
I don't think the direct process of harvesting is the most important part here, but getting an "official" image out there with the bugs fixed... having the fixes in the inbox in mc is not too different then having them in mantis, somehow... people who know that they need them could install them, but the image downloaded does not have them, nor do you see them when loading updates...
Marcus
packages@lists.squeakfoundation.org
-
Avi Bryant -
Daniel Vainsencher -
Marcus Denker -
stéphane ducasse