[PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

Boris Feld boris.feld at octobus.net
Fri May 19 16:02:28 EDT 2017


On Fri, 2017-05-19 at 09:39 -0700, Martin von Zweigbergk via Mercurial-
devel wrote:
> On Thu, May 18, 2017 at 6:18 AM, Augie Fackler <raf at durin42.com>
> wrote:
> > 
> > > On May 18, 2017, at 04:46, Pierre-Yves David <pierre-yves.david at e
> > > ns-lyon.org> wrote:
> > > 
> > > > >    I would recommend the following step forward:
> > > > > 
> > > > >    1) add a simple "rewritten as" template,
> > > > >    2) record action-bit, use it in the template (and other
> > > > > related output),
> > > > >    3) gather data and look at the best way to issue more
> > > > > details.
> > > > > 
> > > > 
> > > > Since we're not sure what we're going to do yet, wasting
> > > > limited bit
> > > > flags when we have an open-ended metadata field is premature
> > > > optimization. I support the approach in this patch. I also
> > > > support
> > > > converting things to bit flags before 4.3 if we establish
> > > > confidence
> > > > that the feature is working how we'd like.
> > > 
> > > We have to keep in mind that the total size of markers is an
> > > important factor here. There are already useful information
> > > excluded from markers for size reason (eg: parent information for
> > > non-prune). We have to keep being careful here and weight what
> > > extra data is the most important. Adding command name would
> > > increase markers size by tens of percent. Especially since
> > > markers will live forever in the project once created.
> > 
> > I understand that, but I think storing the command name is
> > worthwhile as an experiment. I'd like us to be better about letting
> > the perfect be the enemy of the good. I think we should go ahead
> > and land this patch as-is, and if it turns out to be massively
> > unwise we can back it out before 4.3.
> > 
> > Does anyone (other than Pierre-Yves, who has made his position very
> > clear) object (strongly or weakly) to moving forward with this
> > patch as stated?
> 
> I agree with Pierre-Yves that the bit-based solution seems better
> long-term. I'm not particularly worried about wasting bits. I was
> also
> happy for Durham's patch as a short-term solution. But since
> Pierre-Yves et al are already working on the bit-based solution, I'd
> prefer to give them at least a month to make progress on that.
> 
Hi everyone,

I works with Pierre-Yves on Evolve, I wrote the obslog command that was
released yesterday with Evolve 6.2.0. Today I finished a first
experiment on this topic. It is available on the evolve default branch.

I tried an intermediary approach on the subject, I agree that we are
not ready to decide right now how to use the bitfield in obs markers
and that knowing what was the effect of the change is maybe more
universal (what about hg amend that can or not change content but also
the user, date or description).

My approach was to use a bit-field but put it in the metadata under a
"versioned" field (currently: "ef1") so we can change the format, or
totally remove it, in the future without "losing" the bits.

Another change that I made is, instead of asking the command to give
the data, compute what changed directly before creating the obsmarkers.
It's quite naive for the moment but it have the nice property to make
all the commands (from core or extensions) compatibles, instantly
without any extra work. In order to avoid adding overhead for
repositories not willing to test it, I've put it under an experimental
flag: "experimental.evolution.effect-flags = 1".

Finally, I've updated the debugobshistory command to display the effect
flag modifications and it was very straightforward, you can see
examples of output here: https://www.mercurial-scm.org/repo/evolve/file
/tip/tests/test-evolve-effectflags.t. This is a first version, I plan
to keep improving the output.

Now my plan is to get some team of testers to activate it and give
feedback for a couple of week. Once we get happy enough with the result
we'll start upstreaming it. 
I'll activate it on my own repositories, feel free to do it too.
> 
> > 
> > Thanks!
> > Augie
> > 
> > > If exhausting bit flag is a concern, we can easily extend this
> > > bit field. For now, we could store this extension in the metadata
> > > mapping, and we would store them as an extra byte in the next
> > > obsstore format (that we'll need soon at least for hash agility
> > > anyway).
> > > We could easily dedicate a whole byte to store the proposed
> > > action bit (and store it the marker extra for now, that would
> > > help adjusting bit value over time).
> > 
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at mercurial-scm.org
> > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list