A few comments on the workflow document: > The Mercurial ON gate is made up of two Mercurial repositories > > ssh://onnv.sfbay.sun.com//export/gate-hg > ssh://hg.opensolaris.org/hg/onnv/onnv-gate > > These repositories are equivalent, and contain the open source portions > of the ON gate. > ssh://onnv.sfbay.sun.com//export/gate-hg/usr/closed > > This is the repository for the closed code.
Are these still the correct URLs after the rtichk discussion Friday? Also, I wonder if this text is too simple. If you want to pull from onnv.sfbay, you need to pull from the clone (both open and closed repos). And if you want to push to the gate, you need to include the magic user (onhg?). > Get the open source > > hg clone ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate your-ws See http://blogs.sun.com/kupfer/entry/defeating_the_opensolaris_address_mangler for instructions on how to make the URL display properly. > For ON: get the closed source or the closed binaries > > hg clone ssh://onnv.sfbay.sun.com//export/gate-hg/usr/closed > your-ws/usr/closed This should point people at the clone. > ...or just download the closed binaries. This needs to tell people where (or, preferably, link to that information in some other web page). > Have nightly create or update your workspace for you [...] > If $CODEMGR_WS does not exist, then nightly(1) will create it as a > clone of $BRINGOVER_WS. It will NOT, however, create a new > $CLOSED_BRINGOVER_WS if one does not already exist. The last sentence should be deleted to match Mark's recent putback. > Check for nits [...] > Remember that Cadmium does not cross Mercurial repository boundaries, > so must run this separately for usr/closed. "so must" -> "so you must" > Backup your work [...] > To restore your workspace, clone the parent and restore from your > backup: [...] > you will need to restore usr/closed separately, if appropriate. And you'll probably need to merge (assuming the parent has continued to take changesets since the backup was made). > Merging with committed changes [...] > Mercurial will merge the two heads, starting your merge application as > necessary to resolve content changes in individual files, But only if the edits overlap. We really need to make this clear. If people are expecting Teamware-like behavior, they may assume, incorrectly, that because no merge tool was brought up, the only changes to a file are theirs. Ideally people would catch the parent's changes when they do "hg diff" prior to committing the merge, but in a large wad such changes could easily be missed. > Merging with uncommitted changes [...] > If the pull added two heads Can the pull actually add two heads in this case? > Integrating your changes (putback, push) This section needs a sample hg invocation. Don't forget the magic ssh user. > Backing out undesirable changes [...] > If your backout required a merge, you should probably recommit it, as > its function is plain enough, and the extra merge in the history is > not useful to you. I'm not sure the benefit of doing a reci in this situation warrants the complexity of describing it. (That is, it's yet another rule/guideline for people to navigate. Better to just remove it.) mike
