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 <r...@durin42.com> > wrote: > > > > > On May 18, 2017, at 04:46, Pierre-Yves David <pierre-yves.david@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@mercurial-scm.org > > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel > > _______________________________________________ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel