[PATCH 6 of 8] obsolete: exchange obsolete marker over pushkey

[Patrick Mézard]

Le 08/06/12 15:59, Idan Kamara a écrit :
> On Fri, Jun 8, 2012 at 3:25 PM, Patrick Mézard <patrick at mezard.eu> wrote:
>>
>> Le 08/06/12 13:25, Idan Kamara a écrit :
>>> On Fri, Jun 8, 2012 at 1:28 PM, Patrick Mézard <patrick at mezard.eu>
>>> wrote:
>>>>
>>>> Le 08/06/12 11:50, Idan Kamara a écrit :
>>>>> On Thu, Jun 7, 2012 at 8:56 PM, Patrick Mézard <patrick at mezard.eu>
>>>>> wrote:
>>
>> [...]
>>
>>>>> 1) does the 'obsstore' ever shrink or does it grow indefinitely?
>>>>
>>>> It grows indefinitely. This may not be as bad as it sounds in practice,
>>>> there are two extreme cases:
>>>> - Public repositories. They should accept only "killing" markers.
>>
>> (Note the statements above belong to me, I am sure Pierre-Yves has a
>> different take on this).
>>
>>> What if I pushed A by accident, then 'hg amend'ed it (which
>>> presumably says A' replaces A) then pushed it again?
>>
>> I don't know, I am not surprised the first silly idea I wrote does not
>> work well.
>>
>> Are we concerned about the volume of obsolete markers generated on public
>> changesets? Probably not, this should be the exception not the norm, it
>> could be acceptable to exchange these so people use the evolve machinery
> on
>> (rarely) edited public changesets.
> 
> If I understand correctly, 'killing' csets will be the only way to
> strip remotely.
> So I'm not sure this will be the exception, but it probably won't reach to
> concerning quantities on the average repo.
> 
> But it does raise the question if after a cset has been killed (hidden from
> the
> changelog, and possibly garbage collected), do we want pullers to also
> get that information? Or is it sufficient for it to no longer be exposed?

At no point in time you can tell that people having pulled the repository before killing the changeset, have pulled it again after killing the changeset, and thus got the obsolete marker. So the information cannot be discarded.

You may build command to say "remove all markers older than a year" though.

>> Revlog entries can have only 2 parents, while a node may be replaced by N
>> others. And you want to access these N others without having to
>> decode/decompress data. Same thing with other metadata.
> 
> Well, the way I imagined it is the revlog data will be the replacing nodes.
> So if A replaces A', you will get a root in the obsolete revlog with A.node.
> Then if A'' replaces A', it will be a child of that root.
> 
> Why do you necessarily want uncompressed data?

For the same reason you do not want revlog parents in revlog data: speed when traversing the graph. Again, I have no numbers to backup that claim, and the access patterns are not obvious to me right now.

--
Patrick Mézard