This putback changed usr/src/tools/scripts/cddlchk.1 from being a derived
file to being an scm-managed file.
So if you've done a full (or even just tools) build in your teamware
workspace, and you bringover these changes, you will likely see a
complaint much like Suha's from the gk incrementals:
> ERROR [usr/src/tools/scripts/SCCS/s.cddlchk.1]: writable
> `usr/src/tools/scripts/cddlchk.1' exists (ge4)
For Mercurial, the failure will include this message when you attempt to
update your working directory:
> abort: untracked file in working directory differs from file in
> requested revision: 'usr/src/tools/scripts/cddlchk.1'
To fix this proactively, you can simply remove this file, or make clobber
in usr/src/tools, before you do your bringover or hg update.
To fix this reactively, you can simply remove this file, or make clobber
in usr/src/tools, and then do an "sccs get cddlchk.1" in
usr/src/tools/scripts (teamware) or "hg update -C" (Mercurial) after your
bringover or hg update complains.
In both cases, your workspace will have the necessary metadata, so you
should not need to bringover or hg pull a second time.
Duh, sorry about that.
--Mark
On Thu, 10 Jul 2008, Mark J. Nelson wrote:
> Date: Thu, 10 Jul 2008 20:16:03 -0600
> From: Mark J. Nelson <Mark.J.Nelson at Sun.COM>
> To: on-all at sun.com, tools-discuss at opensolaris.org,
> scm-migration-dev at opensolaris.org, on-discuss at opensolaris.org,
> sfw_cteam-ext at sun.com
> Subject: Flag day: ON Developer Tools upgraded to support Mercurial
>
>
> Standard apology for folks on lots of e-mail lists...
>
>
>
> Howdy, Consumers of SUNWonbld--
>
> Today's putback of
>
> 6538468 add Mercurial support to ON developer tools
>
> constitutes a flag day for build machine maintainers, and for all users of
> the Mercurial-aware tools delivered thus far by the scm-migration project;
> and a minor heads up for folks that update findunref exceptions.
>
> After tonight's cron jobs run on the gate, you should update the SUNWonbld
> package on your build machines to that provided by the ON Nevada gatekeepers.
>
> For OpenSolaris users, the SUNWonbld.${MACH}.tar.bz2 packages at the
> OpenSolaris Download Center [1] will be updated in a day or two. I (or the
> ON gatekeeping team) will follow up to the opensolaris.org recipients of this
> message when that has happened. At that time, the SUNWonbld downloads from
> the scm-migration project page [2] will no longer be updated.
>
> On any machine running Mercurial and the SUNWonbld tools, whether it's a gate
> machine or build machine or developer desktop or whatever, you'll also need
> to make sure that your version of Mercurial is up to date:
>
>> $ hg version
>> Mercurial Distributed SCM (version 1.0)
>>
>> Copyright (C) 2005-2008 Matt Mackall <mpm at selenic.com> and others
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> Locally applied patches:
>> patchlist: enable a list of patches in 'hg version' output
>> hg-issue1052: diff -g copy handling is oddly filename dependent
>> $
>
> ...if that first line shows less than "1.0," you'll need the SUNWmercurial
> package from build snv_88 or later. Internal users can get this via the
> update_sfw script in /ws/onnv-gate/public/bin. External users should install
> an SXCE build no less recent than snv_88.
>
> Of course, it's good practice to use no older than N-2 for your build machine
> anyway, and since N is currently 95, this part won't require any special
> action if your build machines are reasonably up-to-date.
>
> If you're not yet using Mercurial, that's all you need to know for now.
> Everything should continue to function normally. If you have problems
> building opensolaris, please continue to use the usual alias for help. If
> you're not sure what alias this should be, go with the friendly folks
> at osol-help at opensolaris.org. If your problems are tools-related, rather
> than build-related (we understand it's not always easy to tell the
> difference), then hit us (the project team) up for help at
> scm-migration-dev at opensolaris.org.
>
> If you're using Mercurial, and especially if you're getting ready to convert
> a wx-managed Teamware workspace to use Mercurial, please start with the
> hgsetup(1) [3] and wx2hg(1) [4] manpages.
>
> The findunref heads up part: There are (un)changes to the exception_list
> format, and the exception_list itself has become a derived file.
>
> During development of the scm-aware tools, findunref was changed in a way
> that required directory entries in the exception list to be suffixed with a
> "/*" wildcard.
>
> Prior to putback, this change was removed, but some projects that had used
> scm-aware tools during development managed to squeak into the gate without
> adjusting their findunref exception list entries. That was harmless, but I
> have cleaned it up.
>
> So from here forward, please do what you always did: if you want to prune an
> entire subtree from the findunref checks, just make a single entry for the
> root of the subtree.
>
> Which brings us to the question "where do I put those new entries?" For that,
> please refer to the new README for findunref exception_lists [5]. Obviously,
> that link will take a little while to become active.
>
> Or just don't add any unreferenced files; that's really better, don't you
> think?
>
> That's all for now, watch this space for more general information on the
> transition to Mercurial.
>
> --Mark, who is nothing if not verbose
>
> [1] http://dlc.sun.com/osol/on/downloads/current/
> [2] http://opensolaris.org/os/project/scm-migration/
> [3] http://cr.opensolaris.org/~mjnelson/toolsreview/hgsetup.pdf
> [4] http://cr.opensolaris.org/~mjnelson/toolsreview/wx2hg.pdf
> [5] http://cr.opensolaris.org/~mjnelson/toolsreview/README.exception_lists
>
