[Python-Dev] Backport troubles with mercurial

[Stephen J. Turnbull]

R. David Murray writes:

 > I thought Amaury was saying it was harder than svnmerge, not harder
 > than patching by hand (ie: that it *was* patching by hand, including
 > .rej files and the lack of tracking).  I also heard Georg say that this
 > should be fixable, and that he's partly fixed the tracking issue,

I don't see why the tracking issue is any different than it would be
for svn.  If you're actually merging, either a dummy merge (what git
calls an "ours merge") or reverting unwanted patches will "block"
them, and hg will keep track of the ones that have been merged.  If
you're actually cherry-picking, then you have to keep a separate
database of the patches that have been picked and those that are
blocked, but this has been done successfully for years with svnmerge,
right?

 > but not the patch/merge issue (and that doing so will require a change
 > in the hg core).

I don't think so.  For merges, there isn't a problem.

For cherypicking, I haven't thought carefully about this, but ISTM
that "hg export | hg import; merge post-patch /dev/null source" should
give the traditional conflict markers.  This will require a bit of
care to get the files to merge right, since there will in general be
multiple files that fail to patch, but the names can be fished out of
the .rej file(s).  Getting the source files will also be mildly
tricky, since they live in a different branch, and aren't available in
your local repository.  It will also require a bit of care to get the
commit log etc right.  But I don't think it's that hard, conceptually.

Of course it's preferable to get this feature in hg itself, but I
don't think we need to wait for hg/maintain a fork.

 > Well, considering that the transition is "soon", the fact that it
 > is a SMOP is a concern :)

Sure, but in this crowd, I wouldn't waste a good worry on this
particular SMOP.

 > Well, there will be *some* workflow change since we're talking about
 > committing to 3.2 maint before the new trunk instead of vice versa.
 > But you are right that that is, mostly, a detail.

AFAIK that's not hg-driven, though.

 > I'm not as convinced that changes in workflow will be that minimal,
 > though.  I don't have much experience with the dvcses yet, but what
 > experience I have had leads me to think that understanding the DAG is
 > a non-trivial and necessary mental leap and does affect the workflow.

Yes, no, and yes.  That is, although understanding it is nontrivial,
and once you do it will affect your workflow, it is unnecessary.  The
Emacs crew have proved that to my satisfaction; there are a bunch of
folks there who understand DAGs quite well, but there are also a bunch
who just don't want to know -- and they're doing fine.  True, making
the most of dVCS requires "understanding the DAG."  Adapting an
existing complex workflow to a new dVCS's commands also requires
understanding the DAG.

But using the adapted workflow simply requires learning new names for
old operations.  Annoying, but it will make a fair number of core devs
quite happy.

 > Well, I hope you are right.  I'm looking forward to the new version of
 > the test repository and doing some real world experiments.

Yup.  It's always risky to predict, especially the future<wink>, but
I'm pretty confident that things will work out.  We do need to (1)
make sure we do everything for hg that we've always done for svn, (2)
work out some features that hg doesn't have yet (Windows EOLs), and
(3) listen carefully to those who are testing out the new repository
-- there are always surprises in this kind of thing.  But Python does
that kind of thing very well.