Evolve feedbacks

Wed May 20 09:10:22 UTC 2015

Le 20/05/2015 02:06, Matt Harbison a écrit :
> On Tue, 19 May 2015 03:07:21 -0400, Gilles Moris 
> <gilles.moris at free.fr> wrote:
>
>> I am currently a beginner with evolve, though I have followed the 
>> introduction of the concepts those last years.
>>
>> Currently, I am a MQ user. I introduced its usage at work, and 
>> everybody is pleased with its use, though it have some limitations 
>> that evolve remedy elegantly.
>> First, I am overall pleased with the usage of evolve, so I won't come 
>> back on its intrinsics quality, like non destructiveness, easy 
>> merging of downstream patches, etc...
>>
>> So below is what I am missing currently. May be some of those already 
>> exists.
>>
>> - I would have expected an "evolve --list", much like there is a 
>> "resolve --list". Basically, I need a roadmap of all the evolutions I 
>> need to perform to stabilize my work tree. I guess this could be 
>> partially addressed with some revsets, or "summary --verbose". But I 
>> am expecting more than that. What are the suspended changesets that 
>> make some commits unstable ? What is the public commit that bumped my 
>> changeset? What is the list of divergent commit? I would expect an 
>> "evolve --list" to give that. Giving the phases in the summary 
>> command was part of the same move.
>>
>> - Even though evolve is non destructive, it is not obvious how to 
>> recover that past information:
>>    * I use allprecursors() revset to get access to that, but for a 
>> typical user, it is not very easy to understand which revset to use. 
>> In addition, it usually won't display anything, which is my second 
>> bullet:
>>    * I think some revsets, implying hidden commit should probably 
>> implicitely trigger --hidden. I don't know if this can be considered 
>> a bug, but having to do: "hg log -r 'hidden()' --hidden" seems weird. 
>> And the "--hidden" flag is not very dicoverable, buried in hg help -v 
>> (which might be on purpose). The same could apply to precursors(), 
>> successors().
>
> I thought there was a bug written for this, but maybe it was just 
> recent chatter on the main mailing list.
>
>>    * Is there a way to display the meta-graph of the precursors / 
>> successors of a commit ? This would enable to show how we get to a 
>> particular commit.
>
> You mean this?
>
>     $ hg log -G --hidden -r "allprecursors(26993)"
No, this shows the graph of the mercurial revlogs. What I would like is 
a graph of the obsolescence markers.

>
>>    * By extension, I would like to see the incremental diffs 
>> introduced by each  precursor. A dumb implementation for a linear 
>> obsolete meta-graph can be made by doing repeatidly: "hg diff 
>> --hidden --rev precuror1 --rev precursor2". Note again --hidden 
>> needed. Note also that rebase will bring unrelated changes into the 
>> diff. But at least, that's a start.
>
> I miss this a lot from my MQ usage- the ability to see just how my 
> changes were impacted:
>
>     $ hg ci --mq
>     $ hg pull
>     $ hg rebase -s qbase -d tip
>     $ hg bcompare --mq
>
> Here's a crude script I use to get roughly the same as the last line, 
> so that it avoids all of the noise in the linear diff:
>
> #!/bin/sh
>
> node=$1
> #hash1=$(hg --hidden log -r "limit(precursors($node),1)" -T 
> "{node|short}")
> #hash2=$(hg log -r $node -T "{node|short}")
> hash1=$(hg --hidden log -r $1 -T "{node|short}")
> hash2=$(hg --hidden log -r $2 -T "{node|short}")
>
> hg --hidden export -r "$hash1" -o '/tmp/%h.patch'
> hg --hidden export -r "$hash2" -o '/tmp/%h.patch'
>
> echo "comparing $hash1.patch to $hash2.patch"
> bcompare.exe "/tmp/$hash1.patch" "/tmp/$hash2.patch"
>
>
> Just invoke it like:
>
>     $ odiff.sh 'precursors(x)' x
Thanks!
>
> Obviously I can't put this in contrib with the diff tool hardcoded and 
> no cleanup, so I started trying to wrap extdiff.  But I ran into some 
> issues, and haven't gotten back to it in awhile.  I took out the 
> internal precursors assumption, because it is also useful to compare 
> grafts.  BTW, the odiff name comes from the 'odiff' command evolve 
> adds, but I think that it includes the linear noise.
>
>
>> - With prune, you can remove a patch in a linear series. How do you 
>> do the reverse? Insert a new patch in a linear series. AFAICS, this 
>> implies: hg update + hg commit + hg rebase. Right? If yes, this may 
>> deserve a command, much like prune.
>>    * Related: what would be the equivalent to: hg qpush --move. A few 
>> rebase?
>
> I think that makes sense.  I don't use histedit, so maybe there's a 
> better way.  It's not specifically mentioned here, but this is an MQ 
> -> evolve cheatsheet:
>
>     http://mercurial.selenic.com/wiki/MqDeprecationPlan
Yes indeed, hg graft -O seems to do it. 
http://evolution.experimentalworks.net/doc/from-mq.html
I still think there might be in the end a specific command for that.

Thanks.
Gilles.

>
>>    * Generalization: how do you handle patch re-ordering with evolve?
>>
>> - I did not find any high level roadmap of the roll out of evolve. 
>> Will it be merged back in the main HG repo as an extension? What are 
>> the condition for that? What is the plan to merge it as standard HG 
>> commands? When will that happen? What is missing for that to happen?
>>
>> Regards.
>> Gilles.
>> PS: given the low traffic on evolve mailing list, should this go to 
>> mercurial-devel instead?
>> _______________________________________________
>> Evolve-testers mailing list
>> Evolve-testers at selenic.com
>> http://selenic.com/mailman/listinfo/evolve-testers