during the integration I was thinking that we kept the complete ancestry. I thought that since we merge all the times, the ancestry is kept. My idea is that after just taking Pharo would be enough to merge. Now this is not the case: if I look at Polymorph-Widgets for example I have holes and this is probably due to a load versus a merge. Lukas may be you know more than me on the topic. What do you think? Stef
during the integration I was thinking that we kept the complete ancestry. I thought that since we merge all the times, the ancestry is kept. My idea is that after just taking Pharo would be enough to merge.
Can you elaborate? I don't understand the last sentence.
Now this is not the case: if I look at Polymorph-Widgets for example I have holes and this is probably due to a load versus a merge.
There is not much of a difference between the two: - When loading the working copy has the loaded version as an single ancestor. - When merging the working copy has the previously loaded version and the merged version as an ancestor. In either case there is never a hole. Each version stores the complete ancestry tree it knows, that is the filename and uuid of each version. The problem you run into is that you delete and move version files. If Monticello cannot find the files that it refers to in its ancestry you cannot merge automatically. That's why repositories should strictly be read-only. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
during the integration I was thinking that we kept the complete ancestry. I thought that since we merge all the times, the ancestry is kept. My idea is that after just taking Pharo would be enough to merge.
Can you elaborate? I don't understand the last sentence.
I was thinking that the Pharo repository alone would be enough to make sure that we can always merge.
Now this is not the case: if I look at Polymorph-Widgets for example I have holes and this is probably due to a load versus a merge.
There is not much of a difference between the two:
- When loading the working copy has the loaded version as an single ancestor.
- When merging the working copy has the previously loaded version and the merged version as an ancestor.
In either case there is never a hole. Each version stores the complete ancestry tree it knows, that is the filename and uuid of each version. The problem you run into is that you delete and move version files. If Monticello cannot find the files that it refers to in its ancestry you cannot merge automatically. That's why repositories should strictly be read-only.
I do not really understand how we ended up with holes then. Stef
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In either case there is never a hole. Each version stores the complete ancestry tree it knows, that is the filename and uuid of each version. The problem you run into is that you delete and move version files. If Monticello cannot find the files that it refers to in its ancestry you cannot merge automatically. That's why repositories should strictly be read-only.
I do not really understand how we ended up with holes then.
I guess I will have to explain it on a white-board, but here's another try: The problem is that Monticello cannot find the common ancestor because you deleted it from its repository. To fix the problem you have to find this version and tell Monticello where it can load it from by adding that repository. It is likely that you find the version somewhere on SqueakSource or in some package-cache on your machine. If you can't find the version you have to merge manually. This means you browse the other version or you calculate the changes between your version and the version you want to merge and apply the changes that you think should go in manually one-by-one. Then you 'adopt' that version to the ancestry. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mar 24, 2010, at 7:11 PM, Lukas Renggli wrote:
In either case there is never a hole. Each version stores the complete ancestry tree it knows, that is the filename and uuid of each version. The problem you run into is that you delete and move version files. If Monticello cannot find the files that it refers to in its ancestry you cannot merge automatically. That's why repositories should strictly be read-only.
I do not really understand how we ended up with holes then.
I guess I will have to explain it on a white-board, but here's another try:
The problem is that Monticello cannot find the common ancestor because you deleted it from its repository. To fix the problem you have to find this version and tell Monticello where it can load it from by adding that repository. It is likely that you find the version somewhere on SqueakSource or in some package-cache on your machine.
I know that ;)
If you can't find the version you have to merge manually. This means you browse the other version or you calculate the changes between your version and the version you want to merge and apply the changes that you think should go in manually one-by-one. Then you 'adopt' that version to the ancestry.
Yes this is for the me the minimum I would like to have instead of an error. Also during the manual merge we do not have to give up the fact that superclass, adding new method first... should be changed first and all the logic Stef
participants (3)
-
Lukas Renggli -
stephane ducasse -
Stéphane Ducasse