On Nov 4, 2009, at 3:53 PM, Lukas Renggli wrote: > Can you elaborate the ancestry of the code? > > - What is the ancestry of your image? > (e.g. 11005, 11010, 11030) > > - What is the ancestry of the code you merge? > (e.g. 11005, 11010, XXXX)
lukas you can see the scenario I described using the 11a image up to 11030 and select headingRemoval of Jannik. > In the example above the common ancestory is 11010. So what Monticello > does is to load the delta between 11010 and Janiks branch XXXX. If > this does not touch any changes that have been made between 11010 and > 11030 there is no conflict and that can be merged automatically. Lukas in my example in fact Presenter was removed as well as other methods. Then since they were present at the time jannik commited they reappear when I merge and I do not see why they are not at least tagged with conflicts. >> I have a question. >> Imagine the following scenario. >> - jannik used 11005 to remove heading. In his version >> morphic has the >> class Presenter as well as methods in other classes related to etoys. >> - in 11010 we remove Presenter and other methods. >> >> - now in 11030 I'm merging Jannik changes and >> I do not understand why Presenter and the methods that were >> remove in >> 11010 are not in conflicts. >> I see just that Presenter and the methods removed are added >> again. >> Did I miss something obvious? >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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
