On Mon, Apr 04, 2011 at 12:00:01PM +1000, James C. McPherson wrote: > On 4/04/11 11:56 AM, Richard Lowe wrote: > >Having merge changesets in a project gate is utterly sensible. > > I agree - but I don't want them in ON.
But when prepping a project to push to ON, isn't the standard operating procedure to clone a child repo of the project gate and do a hg recommit in the child to create a single changeset with everything collapsed and then push that back to ON? Doesn't that take care of the two parent issue when merge changesets are pushed to the project gate? The issue I have related to this is how to rebase a project gate without creating a merge changeset that is pushed back to the project gate. When I was looking for information on how to rebase I was pointed to this webpage: http://hub.opensolaris.org/bin/view/Community+Group+tools/hg_workflow by someone who was gk'ing another project gate. To quote that doc: - Syncing up with your parent gate: At intervals, you're going to want to sync your project gate with its parent (onnv-gate, for instance). You probably want to do this on a regular schedule and at suitable points, what this schedule or these points are is entirely up to you, though we would advice you not merge constantly, both for the sake of providing you a stable basis for work, and to avoid filling your project gate history with minor merges. Merging as builds close may work fine in many cases, others may have different preferences. ======================================================================= Syncing with the parent is different in the case of the project gate, as you wish to preserve history of the merge, among other things. - Clone a fresh child of your project gate You should never do real work directly within your project gate, do the work in a child and push the changes to your gate when you are finished, as normal. Pull from your project gate's parent at the point you wish to sync up with your-machine:.../your-gate-merge% hg pull -r <revision or tag> your-gate-<parent> - Merge the head from your project with the head from the parent your-machine:.../your-gate-merge% hg merge Note, The above did not specify the -u flag, so the working copy remained at the head of your project, this way your project is the first side of the merge, and the parent the second. Commit your merge Commit the merge, using some sensible message of your choosing, maybe something like sync with onnv_97. Building the merge If you intend to run the merge through a full build to verify it, you'd be well served to build in children of the merge workspace, leaving the workspace in which you performed the merge free of detritus. Make sure everything is as you expect The first few times through this, you may wish to use Cadmium's hg list and hg pdiffs with the -p option to specify which parent to use, to make sure that the changes relative to your project gate and/or its parent are as you expect. Push the merge to your project gate - Push the changes out to your project gate (this pushes a merge changeset to the project gate). Warning, DO NOT recommit the merges used to sync your project gate with its parent. There are multiple reasons for this. - They represent valuable history to you and the rest of your project. … so you don't want them to go away. - There is no good way to achieve this. If you recommit relative to your project gate, you will not only remove the merge changeset you created, but also the changesets from your project gate's parent since, relative to your project gate, those changes are local to your merge workspace. So when you do this, you're throwing out a lot of history from the parent of your project gate. This is not fatal, in that when you next sync up, you'll pull all that history again, then merge it again, but you're making work for yourself as well as throwing away information. Eventually, when you plan to integrate, you would have to pull all this history (throughout the life of your project), and recommit again against the gate to which you intend your project to integrate. Don't do it. ======================================================================= So is this wrong? If so, what is the correct procedure for rebasing a project gate and where is that documented? If it isn't wrong then there should be a gate tools config parameter to allow merge changesets. -- Will Fiveash Oracle http://opensolaris.org/os/project/kerberos/ Sent using mutt, a sweet, text based e-mail app <http://www.mutt.org/> _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
