This is normal because ancestry cross over repository.
I think that there is something really strange. EIther you get a truly 
distributed system or you get a local.
With MC you get a distributed which can be brittle (even if I understand well 
the problem ancestry is solving).
I think that a pessimistic merge (more than just going one by one on the 
changes would help).

Stef



On Mar 24, 2010, at 8:12 PM, Dale Henrichs wrote:

> Stef and Lukas,
> 
> The other situation that I have seen these types of errors is when the 
> package that I am merging into(?) does not have the repository where the 
> common ancestor mcz file is located.
> 
> For example if I have Seaside.gemstone-dkh.500 with 
> http://seaside.gemstone.com/ss/seaside in it's repository group. When I 
> attempt to merge Seaside.lr.505 in http://www.squeaksource.com/seaside I get 
> an error.
> 
> If I add http://www.squeaksource.com/seaside to the repository group for 
> Seaside.gemstone-dkh.500 and then try the merge, it works..
> 
> Does this help or have I missed something along the way:)
> 
> Dale
> ----- "Stéphane Ducasse" <[email protected]> wrote:
> 
> | On Mar 24, 2010, at 6:46 PM, Lukas Renggli wrote:
> | 
> | >> what is strange is that when I merge the latest loaded version I
> | got the normal "no changes"
> | >> and I could merge without having to add a new repository.
> | > 
> | > Sure, because in this situation the common ancestor is the version
> | you
> | > load (so it can always be found). And the delta between the working
> | > copy and the version you merge is empty, so you have no changes.
> | 
> | You did not get me right
> | 
> |     scenario 1: I click on the slice press merge get an error ancestor
> | not found
> |     scenario 2: I click on the **latest working copy version* that led to
> | the error of scenario and do merge I get no changes of course
> |      + scenario 1 and it merges without the error of scenario 1 (it means
> | that he suddenly magically found the ancestry)
> |     
> | for me there is a bug. Because between scenario 1 and 2 there is no
> | difference since this is exactly the same version that I have 
> | as working copy.
> | 
> | > 
> | >> I think that in squeak they cut the problem (if you do not have the
> | history what do you do).
> | >> You should still be able to merge.
> | > 
> | > I don't think they do anything different? If the ancestor version
> | is
> | > missing you simply cannot do a meaningful merge. It is as simple as
> | > that.
> | 
> | Yes i see what you mean. You cannot use the ancestry to do a clever
> | merge.  What I meant is that we should be able to see what changed
> | based on the latest loaded version (no need to have the complete
> | ancestor since it is broken).
> | 
> | Because often using the latest working copy and having the diff is
> | only what I need. Is whatI'm sayign make sense?
> | 
> | 
> | _______________________________________________
> | Pharo-project mailing list
> | [email protected]
> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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

Reply via email to