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

Pierre-Yves David pierre-yves.david at logilab.fr
Fri Jun 8 09:19:57 CDT 2012


On Fri, Jun 08, 2012 at 04:59:21PM +0300, Idan Kamara wrote:
> 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?
> 
> >
> > 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.
> 
> Yeah, that's why I thought it might not fit. But this can be indexed to make
> answering the question "does node X have any obsolete info?" fast.
> 
> >
> > 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?
> 
> (btw, I might be talking nonsense here and it is completely a bad fit)

Yes, obsolete marker create a DAG.
No, this DAG does not help during exchange :-(

mercurial changeset create a consistent DAG: If I have revision X, I do have
all it's ancestor. This allow us to make discovery based on know heads as head
define a whole subset.

But is you have a marker that use X as a successors, you do not have any
garantee to have all marker that eventually ends up on X.

We can't reuse revlog logic here.



-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120608/c61c9f25/attachment.pgp>


More information about the Mercurial-devel mailing list