Obsmarkers exchange between crew and main (formely: Re: mercurial/crew at 21816: 7 outgoing changesets)

[Pierre-Yves David]

On 06/23/2014 07:35 PM, Matt Mackall wrote:
> On Mon, 2014-06-23 at 19:13 +0100, Pierre-Yves David wrote:
>>
>> On 06/23/2014 07:10 PM, Matt Mackall wrote:
>>> On Mon, 2014-06-23 at 03:47 -0700, Pierre-Yves David wrote:
>>>>
>>>> On 06/18/2014 04:00 AM, Mercurial Commits wrote:
>>>>> 7 outgoing changesets in mercurial/crew:
>>>>
>>>> Can someone from crew pull main into crew to suppress this message?
>>>
>>> Can we automate the transfer of just obsolete markers?
>>
>> Now that we have smart excahge, will excahgne the marker only if the
>> successors are also exchanged.
>
> First, are you sure? I pull from crew/clowncopter and constantly get "no
> changes found" followed by 10 seconds of OBSEXC.

I'm sure that the smarter exchange (in place since March) is only trying 
to exchange markers "relevant to" changesets common to source and 
destination.

This does not mean that the exchange itself is perfect. The discovery is 
slow and buggy hence the delay. My statement that the exchange needs 
more work is not just a conversation filler ;-)

> Second, I think that the above is a pretty clear use-case for exchanging
> markers even if no changesets are exchanged.

I'm certain we do not want this as the default behavior.

Alice's repo is

   o C
   |
   o B
   |
   o A
   |
   o O

Babar repo is:

     o B'
     |
     o A'
     |
   x | B
   | |
   x | A
   |/
   o   O


If pulling from Babar to Alice pulls markers A ← A' and B ← B', we end 
up with obsoleting  A and B in Alice. C become as unstable changeset. 
But we cannot provide any sensible evolution of C because we lack the 
successors of A and B.

This would also work is alice has B checkout. the pull give a "working 
directory parent is obsolete" but `hg update` would remove the content 
of B alice may be relying on.

(third rephrasing) Pulling obsolescence markers without the successors 
transforms a  replacement into a pruning. Confusing and misbehavior 
would ensue.



So maybe we are in a special case that could requires a change in 
behavior with extra configuration. But even if we change obsmarker 
exchange, we would still have trouble with other aspect of the sync. For 
example, the @ bookmark will still be on the (now obsolete) heads, 
keeping the obsolete branch alive. We would need the new heads to 
properly propagates the bookmarks.


In my opinion we should make a full forward synchronization and pull 
main into crew.

-- 
Pierre-Yves David