The "flag day" part:
The frozen-in-time, onnv_96 Mercurial repository has moved. It is now
located at the following paths:
/net/onnv.sfbay/pecos/clones/onnv-hg
ssh://onnv.sfbay//pecos/clones/onnv-hg
If you refer to this repository, either as a default path in one of your
converted repositories or via hg_twin in a local teamware clone, then you
must change to use the new path. Use "hg reparent" in both open and
closed repositories to do this, or simply edit Codemgr_wsdata/hg_twin.
These changes do NOT affect the locations of the current clone repository,
or of the onnv_96 teamware clone workspace.
The details:
The path /export/clone-hg was an attractive nuisance. The existence of
"onnv-tw-clone," "clone-hg," and "onnv-clone" was confusing several
gatelings, and the consequences of choosing poorly range from frustration
to mismerge.
So here's the wx2hg story:
1. The official, gk-maintained teamware parent for workspace conversion
should be /net/onnv.sfbay/export/onnv-tw-clone. It is acceptable to
use a different workspace, as long as it is strictly frozen at onnv_96.
This is not changed, and if you were already doing this correctly, you
should see no problems.
2. The official, gk-maintained Mercurial twin repository for workspace
conversion should be ssh://onnv.sfbay//pecos/clones/onnv-hg. It is
acceptable to use a different repository, as long as it is strictly
frozen at onnv_96, OR you use the "-r onnv_96" argument to wx2hg.
This has changed, so if you have a Mercurial repository with the old
default path, Mercurial will now fail when it attempts to access your
default path.
Some common problems using wx2hg:
Almost all problems reported stem from one of the following errors:
1. Using the wrong Teamware parent workspace:
The parent of your wx-managed Teamware workspace should be either the
official /net/onnv.sfbay/export/onnv-tw-clone, or a workspace known to
be up-to-date with onnv_96.
2. Using the wrong Mercurial repository:
If you allow wx2hg to create your Mercurial repositories, then the
hg_twin file in the Codemgr_wsdata directory of your parent workspace
(NOT your development workspace) must be either the official
ssh://onnv.sfbay//pecos/builds/onnv-hg, or a repository known to be
frozen at onnv_96.
If you cannot control updates in your Mercurial parent repository, or
if you are converting into an existing repository, then you should use
the "-r onnv_96" option to wx2hg.
3. Using wx2hg in a wx-managed workspace in which you have NOT done a
bringover and resolve:
If the parent of your teamware workspace is up to date with onnv_96,
and your Mercurial repository is up to date with onnv_96, but your
development workspace is NOT, then you risk inadvertently reverting
changes that were putback to the Teamware gate after your last
successful bringover.
4. Failing to carefully review a converted repository:
Just like with any merge operation, you are responsible for carefully
reviewing the results of workspace conversion. Using webrev in both
old (teamware) and new (Mercurial) workspaces now, before you commit
your changes, can save you a world of trouble later.
And to be on the safe side, it's useful to commit your converted
workspace with a comment like "converted from wx to hg," so that you
can later review the conversion, in case you find problems. If you
don't do this, and continue to edit files in the new repository, you
won't be able to tell later what was part of the conversion and what
was subsequently edited.
