About MC

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

I do not really understand how we ended up with holes then.


Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Mar 24, 2010, at 7:11 PM, Lukas Renggli wrote:

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
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project