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

Patrick Mézard patrick at mezard.eu
Fri Jun 8 07:25:59 CDT 2012


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.

The problem is with markers generated in the draft phase. In my opinion, they should be discarded a way or another *by default* when the changeset becomes public. Sure, if you are working collaboratively on changesets and you decide to publish them out of the blue, your coworkers would need these markers. Obsolete being designed around the assumption that markers should be exchanged all the time between everyone because you do not know who or why people push or pull from your repositories is probably what I dislike most about the current design. It handles corner cases correctly, but the price seems too high, especially to allow collaborative editing of changesets which, while nice on the paper, looks like a power-user feature.

The workflow would look like:

- create a draft revision
- edit it alone or with people, generating a precursors etc.
- before publishing, if working with other people, push once to the draft repository to ensure markers related to pushed changesets will be available in the future.
- turn the changesets public and discard all markers information not linking it to another public changeset (that is, handle the case of public changesets editing).

No idea how hard this is to implement.

>>> 4) have you considered using a revlog as the storage model?
>>
>> Markers are append-only, not sure revlog would help here.
> 
> So are revlogs?

OK, I only saw the storage part when answering, not the exchange protocol part.

> Also, if I understand what evolution is doing behind the scenes,
> it's looking at the markers and builds some sort of DAG (not explicitly)
> to understand who replaced what.

So yes, they are similar in the fact they represent DAGs. But revlog entries are node -> parents, while obsolete one are node -> replacements, so the relation is reversed. Maybe that is not the right way to do it, but it let you tell whether a node is extinct or replaced and by who, which seems to be the basic operation.

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.

--
Patrick Mézard


More information about the Mercurial-devel mailing list