> I decided to write up a friendlier introduction to wx2hg than we have
> currently, and to publish it on my blog. It doesn't look like
> blogs.sun.com will let anyone other than me see drafts, so I've posted a
> draft at http://cr.opensolaris.org/~kupfer/wx2hg.html. If you have any
> comments, please let me know. I'd like to publish this Monday or
> Tuesday, so a quick review would be appreciated. (Most of the text is
> sample output, so it should be a quick read.)
In the introductory paragraph, the next-to-last sentence might read more
naturally as "So we need to provide support for work in progress, which
began using Teamware, but must eventually integrate using Mercurial."
The page should probably provide a pointer to wx2hg, or at least a
statement of the form "this script is currently part of the tools download
at [pointer], and will be part of the standard SUNWonbld tools when the
SCM migration team does its first putback."
The second "Let's walk through an example" is extraneous.
This covers workspaces that are once-removed from the onnv-clone, but not
project workspaces used to aggregate work from multiple developers. I
don't have the wx2hg script in front of me; is that something that can be
done gracefully, by first converting the project gate to mercurial, and
subsequently using it as the clone for developer workspaces?
For folks that use zfs to manage workspaces, is there a missing step here,
wherein they'll need to zfs create the destination filesystem? (I.e. I
use a zfs dataset pecos/space/builds/mjnelson on elpaso, and create
a single filesystem in that dataset for each workspace that I use; this
script would, if I had sufficient write permissions, create the workspace
in the dataset, rather than a child filesystem.)
For the forward reference ("There's more that wx2hg can do..."), it would
be good to provide a pointer to a manpage.
--Mark
