On Jun 25, 2013, at 10:40 PM, Camillo Bruni <[email protected]> wrote:

> 
> On 2013-06-25, at 19:19, Stéphane Ducasse <[email protected]> wrote:
> 
>> Imagine that you have a conflict because a method changed in the image
>> and that the resolution is please keep the version that was in the slice, 
>> then you republish a slice with the same method and when the integrator will 
>> do 
>> merge he will get again: there is a conflict with the different version that 
>> it is the image.
>> So from a person performing a fix there is no way that I can produce a slice
>> that does not produce a conflict.
> 
> why would that be? the new slice will have the changed method in it.
which new method?
because it is the same than it got already before!

Here is what I did:
        took the slice, merge and for one conflict I said keep incoming
        republish the slice

        => when I remerge on a new image 
        then what? I have a conflict why?
        Because there is still in the ****image*** the same method that changed 
since I publish 
        my slice and my slice that contains always the same methods that I want 
to keep.

Did this scenario work for you?
Because today it did not work for me.



> this is what I do all the time I have a big change and It doesn't get 
> integrated but I have
> to keep it up to date with the image.
> - reload the slice
> - do the manual merging
> - recommit the slice again
> 
> maybe we're thinking of something different.




> 
>>> I don't understand. If you merge and recommit it is fine, since the new 
>>> slice will have different ancestors the 3-way merge won't complain a second 
>>> time, no?
>>> 
>>> On 2013-06-25, at 11:49, Stéphane Ducasse <[email protected]> wrote:
>>>> Hi guys
>>>> 
>>>> I do not know how I can republish a Slice when there is a conflict. 
>>>> Especially when I merged and say that I want to keep the change I did. So 
>>>> we are in the deadlock. There is no way for the fix producers to indicate 
>>>> that 
>>>> he merged and that his changes should be keep.
>>>> 
>>>> So from a bug integration process this is not really good.
>>>> 
>>>> Stef
>>> 
>>> 
>> 
>> 
> 
> 


Reply via email to