On 04/03/2016 06:09 PM, L. David Baron wrote:
On Saturday 2016-04-02 18:51 -0300, Eric Rescorla wrote:
1. I write a bunch of code, committing along the way, so I have a lot of
commits named "Checkpoint" and "Fix bug" and the like.
2. When it works, I push the code up to the review system for review.
3. In response to review comments, I add a bunch more changes as new
commits and push them up the review system for review.
4. Repeat 2 and 3 until I get r+
5. Squash everything into one commit and land it.
Every time I do #3, it creates a new review request, but as you can see,
this doesn't have any meaningful connection to my local commits, which is a
good thing because while I want to keep my local history, I don't want it
to show up either in review or in the tree. This is also the way I want to
see patches because I want to review the whole thing at once.
This is why I use mq. With mq, I maintain the sequence of
changesets that are the logical units to be committed (and submitted
for review), and I have the history of that sequence (in a
version-controlled patch repository).
It's useful for reviewability and for bisection for the logical
units that I commit to be small and (for review) understandable.
And it's useful for me to have a history of the work I've done, for
backups, for the ability to revert, and for the ability to remember
what I did and why.
I still think this is a good model for doing development, despite
the attempts of Mercurial developers to deprecate it. I recognize
that it's not the right tool for everybody, though.
IMO, mq has a great UI, but it is based on a poor architecture (data
model, really). It duplicates information that the VCS already handles,
and the effects are predictable: things get mismatched, it produces a
whole class of issues resulting from discrepancies between the stores,
and features/improvements must be reimplemented for the mq data model
and often aren't. And yet, the mq user experience is for the most part
very nice and much better than the base workflow that you get with core
hg commands.
Personally, I started with mq, then went through a period where I was
using both mq and core stuff. mq felt more comfortable for a long long
time, but once I smoothed over some of the issues I hadn't really
realized were bothering me, I gradually shifted more and more of my
development towards the non-mq direction. At this point, I have a clear
preference for the non-mq way of doing things, even though my non-mq
workflow still has some gaps. (Those gaps are now smaller than the gaps
in the mq workflow.)
I should clarify that by "non-mq", I really mean using mutable-history
aka evolve. And yes, my workflow does depend on some extensions,
including some local stuff that I haven't cleaned up enough to publish.
(As does my mq workflow; I had to write mqext to get painless versioning
of my patch queue.) So I'm not saying "just switch off from mq to evolve
and everything will be great"; rather I'm saying that with some effort
to get accustomed to the new workflow and some customization, the
evolve-based workflow can feel better than the mq-based workflow, even
if you've built up a set of workarounds and accommodations to mq's
weaknesses that you're comfortable with.
I still have a directory with 145 mq patches sitting in it that I
periodically mine for useful stuff. Enough of the tools I used to
depended on have broken with newer hg versions, so at this point I
generally use it by applying a set of patches with qpush --move,
deleting .hg/patches/status to un-mqify it, and then using my new
workflow to finish things up.
A vague and general statement, to be sure. I keep promising myself that
I'll document my personal workflow and what you need to replicate it. A
capsule summary would be:
1. install mutable-history
2. set [experimental] crecord = True
3. install chistedit from
https://bitbucket.org/facebook/hg-experimental (or
https://bitbucket.org/sfink/hg-experimental for more good stuff, but
I've upstreamed the most important bits). And you may need something
like [alias] che = chistedit -r 'not public() and ancestors(.)'
4. get comfortable with revsets, especially wrt phases ('not public()'
is your friend), and probably create or borrow some work-in-progress aliases
5. enable the firefoxtree extension (via mach mercurial-setup) and use
the 'inbound' alias for pulling and rebasing
For me, the main thing is to stay oriented, and bookmarks plus an alias
to do the equivalent of hg log -r 'ancestors(.) and not public()' go a
long way towards recovering mq's "what am I working on?" qseries -v
affordances. Though I immediately want it to be something closer to hg
log -r 'ancestors(.) and not public()' -T '{node|short} {desc}\n' and
then I want color etc etc... Anyway, I'll document what I have at some
point, and other people have their own things as good or better.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
