Quoth Mike Kupfer on Wed, Aug 20, 2008 at 02:49:00PM -0700:
> I drafted a new version of the hg_workflow page[1], based on my comments
> of August 2nd[2]. I didn't address a few of my comments. In
> particular,
...
> As usual, the draft version and diffs are at
> http://cr.opensolaris.org/~kupfer/on-readme/.
"It is highly recommended that you review the results of a merge
before committing it...": I think you should state how to determine
{which files have changed, what the diffs are, and maybe how to
generate a webrev} relative to each head.
Merging with uncommitted changes: Should you mention that if the
changes aren't committed, then there's no way to rerun the merge,
like you can if they were committed?
Running a project gate: I think the first subsection should be how to
set up a gate for multiple committers. You could say that the
easiest way is to set up the gate on hg.opensolaris.org. And you
could point to documentation on how to set up a repository with
write-access for a group, or how to set up a user for shared-ssh, or
how to do it with httpd, as I've heard is possible.
Pull from your project gate's parent...: This is where I think you
should say how to pull in the changeset which defines a tag, so that
project gatelings can use the tag, too.
Aside: Speaking of which, I've been wondering if we should file
an RFE with Mercurial for an option which pulls not the
changeset for a tag, but the changeset which *defines* the tag.
Like
hg pull -R onnv_96
Except, of course, that -R is already used. Maybe some sort of
defined:onnv_96 syntax could work instead.
Merge the head from your project...: Should you mention interrupted
merges, like you could do with resolve(1), even if the user doesn't
have to do anything special?
David
