OpenSolaris

Printable Version Enter a New Search
Bug ID 6731128
Synopsis nightly + mercurial bringover messaging could be improved
State 10-Fix Delivered (Fix available in build)
Category:Subcategory consolidation:os-net-tools
Keywords
Responsible Engineer Mark J Nelson
Reported Against
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_96
Fixed In snv_96
Release Fixed solaris_nevada(snv_96)
Related Bugs
Submit Date 29-July-2008
Last Update Date 13-August-2008
Description
I recently converted a workspace from teamware to mercurial.  The workspace contains a small number of changes.  I was building it nightly, using nightly's feature supporting a bringover prior to building.

While under teamware, a bringover with conflicts would result in the nightly aborting without building.  The first night I ran within the mercurial workspace I saw the following in my log:

==== BRINGOVER LOG ====

pulling from ssh://elpaso.eng//export/clone-hg
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 8 changes to 8 files (+1 heads)
not updating, since new heads added
(run 'hg heads' to see heads, 'hg merge' to merge)
8 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

Being a bit unfamiliar with mercurial, it wasn't clear to me what this was telling me.  I wondered if perhaps it had found some conflicts but barreled ahead anyway.  Turns out that's not what's happening here, no merges are
required and the build will happen and use the correct source.  My 'working directory' still needs a commit, but that's a different issue.

I think it would be valuable to beef up or clean up the output a little. There's an indication I need to run hg merge, but then the script actually runs it for me without realling telling me so.  A little more info on what it's doing here probably will ease the teamware to mercurial transition.
Work Around
N/A
Comments
N/A