Brian Utterback writes: > One thing I find lacking is a definitive flowchart like set of commands > needed to fix a bug or integrate a project both inside and outside SWAN. > I know for ON work that I start with a clone of onnv and that there are > internal mirrors. But I see that there is a repo called onnv-gate and > onnv-clone. I know why we had that for teamware; which is the right one > to clone from under mercurial? I think there is only onnv-gate outside > SWAN, right?
The one outside the SWAN is currently read-only and contains only the open bits. Assuming you have only changes in usr/src (most projects do), you can sync up your project gate using the external copy, the internal onnv-clone, or any of a number of internal mirrors of onnv-clone. If you have to touch usr/closed, then you'll need to pull those bits _separately_ from one of the internal gates. When pushing changes, you push to onnv-gate, and you do it from your local machine (no more logging into the gate machine -- big change from Teamware). For more information, read through Mark's messages carefully: http://www.opensolaris.org/os/community/on/flag-days/pages/2008081202/ Everything you need to get started is there. > Now that I have my own repo, then what? I presume that I need to run > nightly, but is it best to run it in the repo, or have nightly clone the > repo? I always do nightly builds in child workspaces. Others have different practices. > I know that I don't have to check out files to edit them, but > isn't hg going to have fits if I run nightly in the repo? No. It's probably not the best idea, but it shouldn't harm hg at all. > There was > mention a while back about an extension to cadmium that kept a list of > files in a directory .cdm. What is the advantage of that? Should I get > that extension and install it somewhere? You already have it if you have the current SUNWonbld and if you have the proper $HOME/.hgrc entries. All of the regular build machines have the right packages installed, and your account will be fine if you've run "hgsetup". I looked at ~blu/.hgrc, and you've already got Cadmium set up: hgext.cdm=/ws/onnv-tools/onbld/lib/python/onbld/hgext/cdm.py So ... relax. You're already soaking in it. > In bitkeeper they say to update often to avoid conflicts. Same with > bringovers and teamware. But with hg it seems that this can do something > bad with the changesets, but I am nto sure what. Also, in teamware it > seemed that you didn't want to check in a file until the end, but this > doesn't seem to be true with hg. What is the standard edit-test-edit cycle? I always commit before doing testing. But I always did "wx delget" before testing, so this is no change at all for me. The only important issue I've run into is that you really should commit your local changes before attempting to pull from the clone (that is, before attempting a merge). > Sure things are different than when we used teamware. But I think there > needs to a canonical list of commands needed to develop for OpenSolaris. > Once we have that, then we can start improving on it with tools and > extensions and things. > > Sorry if this wasn't the right thread or forum, but I just spent the day > trying to puzzle this all out myself. There are local folks with some hg and Cadmium experience ... you might want to ask one of them to walk through the commands. :-> -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
