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.